Import Cobalt 16.136005
Change-Id: I2b9198982828ad841d50902b145910c0aeb689d3
diff --git a/src/third_party/skia/site/dev/contrib/c++11.md b/src/third_party/skia/site/dev/contrib/c++11.md
new file mode 100644
index 0000000..432ad88
--- /dev/null
+++ b/src/third_party/skia/site/dev/contrib/c++11.md
@@ -0,0 +1,57 @@
+C++11 in Skia
+=============
+
+Skia uses C++11. But as a library, we are technically limited by what our
+clients support and what our build bots support.
+
+Skia may also be limited by restrictions we choose put on ourselves. This
+document is not concerned with C++11 policy in Skia, only its technical
+feasibility. This is about what we can use, a superset of what we may use.
+
+The gist:
+
+- C++11 the language as supported by GCC 4.7 or later is pretty usable.
+- The C++11 standard library can generally be used, with some teething.
+- If you break a bot, that feature is not usable.
+- Local statics are not thread safe.
+
+
+Clients
+-------
+
+The clients we pay most attention to are Chrome, Android, Mozilla, and a few
+internal Google projects.
+
+Chrome builds with a recent Clang on Mac and Linux and with a recent MSVC on
+Windows. These toolchains are new enough to not be the weak link to use any
+C++11 language feature. Chromium, however, builds against libstdc++4.6.4
+(STL and runtime) on Linux. This precludes direct use of a number of type
+traits.
+
+Chrome intentionally disables thread-safe initialization of static variables,
+so we cannot rely on that. Our bots disable this too, so keep an eye on TSAN.
+
+Android builds with either a somewhat aged GCC or a recent Clang. They're
+generally not a weak link for C++11 language features. Android's C++ standard
+library had historically been a pain, but seems to work fine these days.
+
+Mozilla's current weak link is a minimum requirement of GCC 4.7. Most features
+marked in red on Mozilla's C++11 [feature
+matrix](https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code) are
+marked that way because they arrived in GCC 4.8. Their minimum-supported Clang
+and MSVC toolchains are pretty good, but MSVC 2013 will become the weak link soon.
+
+Internal Google projects tend to support C++11 completely, including the
+full C++11 standard library.
+
+
+Bots
+----
+
+Most of our bots are pretty up-to-date: the Windows bots use MSVC 2013, the Mac
+bots a recent Clang, and the Linux bots GCC 4.8 or a recent Clang. Our Android
+bots use a recent toolchain from Android (see above), and our Chrome bots use
+Chrome's toolchains (see above). I'm not exactly sure what our Chrome OS bots
+are using. They're probably our weak link right now, though problems are rare.
+
+I believe our bots' ability to use C++11 matches Mozilla's list nearly identically.
diff --git a/src/third_party/skia/site/dev/contrib/cqkeywords.md b/src/third_party/skia/site/dev/contrib/cqkeywords.md
new file mode 100644
index 0000000..b21b787
--- /dev/null
+++ b/src/third_party/skia/site/dev/contrib/cqkeywords.md
@@ -0,0 +1,76 @@
+Commit Queue Keywords
+=====================
+
+COMMIT
+------
+
+If you are working on experimental code and do not want to risk accidentally
+submitting the change via the CQ, then you can mark it with "COMMIT=false".
+The CQ will immediately abandon the change if it contains this option.
+To do a dry run through the CQ please use Gerrit's [CQ Dry Run](https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/G5-X0_tfmok) feature.
+
+ COMMIT=false
+
+The CQ will run through its list of verifiers (reviewer check, trybots, tree check,
+presubmit check), and will close the issue instead of committing it.
+
+No-Dependency-Checks
+--------------------
+
+ No-Dependency-Checks: true
+
+The CQ rejects patchsets with open dependencies. An open dependency exists when a CL
+depends on another CL that is not yet closed. You can skip this check with this keyword.
+
+CQ_INCLUDE_TRYBOTS
+------------------
+
+Allows you to add arbitrary trybots to the CQ's list of default trybots.
+The CQ will block till these tryjobs pass just like the default list of tryjobs.
+
+This is the format of the values of this keyword:
+
+ CQ_INCLUDE_TRYBOTS=bucket1:bot1,bot2;bucket2:bot3,bot4
+
+Here are some real world examples:
+
+ CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_asan_rel_ng
+
+ CQ_INCLUDE_TRYBOTS=skia.primary:Test-Win-MSVC-ShuttleC-GPU-GTX960-x86_64-Debug-ANGLE
+
+
+No-Tree-Checks
+--------------
+
+If you want to skip the tree status checks, to make the CQ commit a CL even if the tree is closed,
+you can add the following line to the CL description:
+
+ No-Tree-Checks: true
+
+This is discouraged, since the tree is closed for a reason. However, in rare cases this is acceptable,
+primarily to fix build breakages (i.e., your CL will help in reopening the tree).
+
+No-Presubmit
+------------
+
+If you want to skip the presubmit checks, add the following line to the CL description:
+
+ No-Presubmit: true
+
+No-Try
+------
+
+If you cannot wait for the try job results, you can add the following line to the CL description:
+
+ No-Try: true
+
+The CQ will then not run any try jobs for your change and will commit the CL as soon as the tree is open, assuming the presubmit check passes.
+
+NO_MERGE_BUILDS
+---------------
+
+This keyword prevents the Skia build masters from building this commit with others. Use it when your
+commit may have effects that you don't want mis-attributed to other commits. Just include the keyword
+somewhere in the commit message:
+
+ NO_MERGE_BUILDS
diff --git a/src/third_party/skia/site/dev/contrib/directory.md b/src/third_party/skia/site/dev/contrib/directory.md
new file mode 100644
index 0000000..4edab89
--- /dev/null
+++ b/src/third_party/skia/site/dev/contrib/directory.md
@@ -0,0 +1,43 @@
+The Skia Directory
+==================
+
+* Docs & Bugs
+ - [Skia.org](https://skia.org/)
+ - [Issue Tracker](https://bug.skia.org/)
+ - [Autogenerated API
+ Documentation](https://skia-doc.commondatastorage.googleapis.com/doxygen/doxygen/html/index.html)
+
+* Code Repositories
+ - [Git repository](https://skia.googlesource.com/skia/)
+ - [Other Skia project repositories](https://skia.googlesource.com/)
+ - [Github Mirror](https://github.com/google/skia)
+ - [Code Search](https://cs.skia.org) based on the version of Skia in the
+ Chromium tree.
+
+* BuildBot Consoles
+ - [Commit Status](https://status.skia.org/)
+ - [Tree Status](https://skia-tree-status.appspot.com/) (requires login)
+ - [BuildBot Console](https://build.chromium.org/p/client.skia/console)
+ - [FYI BuildBot
+ Console](https://build.chromium.org/p/client.skia.fyi/console)
+ - [Android BuildBot
+ Console](https://build.chromium.org/p/client.skia.android/console)
+ - [Compile BuildBot
+ Console](https://build.chromium.org/p/client.skia.compile/console)
+
+* Other
+ - [Fiddle](https://fiddle.skia.org/) Try out Skia on the web!
+ - [Gold](https://gold.skia.org/) Correctness testing.
+ - [Perf](https://perf.skia.org/) Performance testing.
+ - [Mon](https://mon.skia.org/) Grafana dashboard (requires login).
+ - [Alerts](https://alerts.skia.org/) Monitor testing and bot status.
+ - [BugChomper] (https://bugchomper.skia.org/) Prioritize bugs quickly.
+ - [Code Review](https://skia-review.googlesource.com/)
+
+* Mailing Lists
+ - [Discussion Mailing List](https://groups.google.com/group/skia-discuss)
+ - [Code Review Announce
+ List](https://groups.google.com/a/skia.org/forum/#!forum/reviews)
+ - [Bug Announce
+ List](https://groups.google.com/a/skia.org/forum/#!forum/bugs)
+
diff --git a/src/third_party/skia/site/dev/contrib/flatten.md b/src/third_party/skia/site/dev/contrib/flatten.md
new file mode 100644
index 0000000..192571e
--- /dev/null
+++ b/src/third_party/skia/site/dev/contrib/flatten.md
@@ -0,0 +1,88 @@
+Flattenables
+============
+
+Many objects in Skia, such as SkShaders and other effects on SkPaint, need to be
+flattened into a data stream for either transport or as part of the key to the
+font cache. Classes for these objects should derive from SkFlattenable or one of
+its subclasses. If you create a new flattenable class, you need to make sure you
+do a few things so that it will work on all platforms:
+
+1: Override the method flatten (the default scope is protected):
+
+<!--?prettify?-->
+~~~~
+virtual void flatten(SkFlattenableWriteBuffer& buffer) const override {
+ this->INHERITED::flatten(buffer);
+ // Write any private data that needs to be stored to recreate this object
+}
+~~~~
+
+2: Override the (protected) constructor that creates an object from an
+SkFlattenableReadBuffer:
+
+<!--?prettify?-->
+~~~~
+SkNewClass(SkFlattenableReadBuffer& buffer)
+: INHERITED(buffer) {
+ // Read the data from the buffer in the same order as it was written to the
+ // SkFlattenableWriteBuffer and construct the new object
+}
+~~~~
+
+3: Declare a set of deserialization procs for your object in the class declaration:
+We have a macro for this:
+
+<!--?prettify?-->
+~~~~
+public:
+
+SK_DECLARE_PUBLIC_FLATTENABLE_DESERIALIZATION_PROCS(SkNewClass)
+~~~~
+
+4: If your class is declared in a .cpp file or in a private header file, create a
+function to register its group:
+This occurs in cases where the classes are hidden behind a factory, like many effects
+and shaders are. Then in the parent class header file (such as SkGradientShader) you
+need to add:
+
+<!--?prettify?-->
+~~~~
+public:
+
+SK_DECLARE_FLATTENABLE_REGISTRAR_GROUP()
+~~~~
+
+Then in the cpp file you define all the members of the group together:
+
+<!--?prettify?-->
+~~~~
+SK_DEFINE_FLATTENABLE_REGISTRAR_GROUP_START(SkGroupClass)
+
+ SK_DEFINE_FLATTENABLE_REGISTRAR_ENTRY(SkMemberClass1)
+
+ SK_DEFINE_FLATTENABLE_REGISTRAR_ENTRY(SkMemberClass2)
+
+ // etc
+
+SK_DEFINE_FLATTENABLE_REGISTRAR_GROUP_END
+~~~~
+
+
+5: Register your flattenable with the global registrar:
+You need to add one line to SkFlattenable::InitalizeFlattenables(). To register the
+flattenable in a Skia build, that function is defined in SkGlobalInitialization_default.cpp.
+For Chromium, it is in SkGlobalInitialization_chromium.cpp.
+For a single flattenable add
+
+<!--?prettify?-->
+~~~~
+SK_DEFINE_FLATTENABLE_REGISTRAR_ENTRY(SkNewClass)
+~~~~
+
+For a group, add
+
+<!--?prettify?-->
+~~~~
+SkGroupClass::InitializeFlattenables();
+~~~~
+
diff --git a/src/third_party/skia/site/dev/contrib/index.md b/src/third_party/skia/site/dev/contrib/index.md
new file mode 100644
index 0000000..9f74a40
--- /dev/null
+++ b/src/third_party/skia/site/dev/contrib/index.md
@@ -0,0 +1,48 @@
+Contributing to Skia
+====================
+
+Here some ways you can get involved and help us improve Skia.
+
+
+Report Bugs
+-----------
+
+Find bugs to fix or report new bugs in the [Skia issue tracker](http://bug.skia.org/).
+You can also search the [Chromium issue tracker](http://code.google.com/p/chromium/issues/list) for bugs related to graphics or Skia.
+
+Test
+----
+
+Write an application or tool that will exercise the Skia code differently than our
+current set of tests and verify that Skia works as expected. Draw something
+interesting and profile it to find ways to speed up Skia's implementation.
+We cannot always fix issues or support every scenario, but we welcome any bugs
+found so we can assess and prioritize them. (If you find _and_ fix a bug, even better!)
+
+Contribute Code
+---------------
+
+Whether you develop a new feature or a fix for an existing bug in the Skia code base,
+you will need a committer to review and approve the change. There are some steps that
+can speed up the review process:
+Keep your code submissions small and targeted.
+When possible, have a fellow contributor review your change in advance of submission.
+Propose new features to the project leads by opening a feature bug or posting to
+skia-discuss ahead of development. For more information, see [How to submit a patch](./contrib/submit).
+
+For background on the project and an outline of the types of roles interested parties
+can take on, see [Project Roles](../../roles).
+
+Anyone contributing code to Skia must sign a Contributor License Agreement and ensure
+they are listed in the AUTHORS file:
+Individual contributors can complete the [Individual Contributor License Agreement](https://developers.google.com/open-source/cla/individual) online.
+If you are contributing on behalf of a corporation, fill out the [Corporate Contributor License Agreement](https://developers.google.com/open-source/cla/corporate)
+and send it in as described on that page.
+If it is your first time submitting code or you have not previously done so, add your
+(or your organization's) name and contact info to the [AUTHORS file](https://skia.googlesource.com/skia/+/master/AUTHORS) as a part
+of your CL.
+REVIEWERS: Before you LGTM a change, verify that the contributor is listed in the AUTHORS file.
+If they are not, a Googler must ensure that the individual or their corporation has signed the
+CLA by searching [go/cla-signers](https://goto.google.com/cla-signers).
+Then have an entry added to the AUTHORS file with the CL.
+
diff --git a/src/third_party/skia/site/dev/contrib/jumper.md b/src/third_party/skia/site/dev/contrib/jumper.md
new file mode 100644
index 0000000..757697f
--- /dev/null
+++ b/src/third_party/skia/site/dev/contrib/jumper.md
@@ -0,0 +1,102 @@
+Contributing to SkJumper
+========================
+
+SkJumper is the execution engine of SkRasterPipeline, a system we've been using
+to accelerate CPU-bound work inside Skia, most notably color-space conversions
+and color-correct drawing.
+
+(This is where I'd put my link to design document if I had one...)
+
+SkJumper is more annoying to contribute to than most Skia code because of its
+offline compilation step. You'll need particular tools installed on your
+machine and to tell GN about them. This document is designed to guide you
+through this process and ease some of that annoyance.
+
+One-time Setup
+--------------
+
+To generate stage code you need Clang 4.0, objdump, and ccache. It's best that
+Clang is exactly the same version we typically use (as of writing 4.0.0) and
+you'll need objdump to be compiled with support for x86-64, ARMv7, and ARMv8.
+
+The easiest way to satisfy these contraints is to get your hands on a Mac and
+install [Homebrew](https://brew.sh). Once you have `brew` installed, run this
+to get the tools you need:
+
+<!--?prettify lang=sh?-->
+
+ brew install llvm binutils ccache
+
+Setting up GN
+-------------------------
+
+With your tools installed, tell GN about them
+
+ skia_jumper_clang = path/to/clang-4.0
+ skia_jumper_objdump = path/to/gobjdump
+ skia_jumper_ccache = path/to/ccache
+
+then regenerate and build as normal.
+
+If you look in your GN out directory, you should now see a bunch of `.o` files,
+and `git status` should show no changes to `src/jumper/SkJumper_generated*.S`.
+That's good. Those object files are the intermediates we parse to produce
+the assembly files. We just leave them around in case you want to look at
+them yourself.
+
+Make A Change
+-------------
+
+Let's use the `from_srgb` stage as a little playground to make a real change.
+Linearizing sRGB encoded bytes is slow, so let's pretend we've decided to trade
+quality for speed, approximating the existing implementation with a simple square.
+
+Open up `SkJumper_stages.cpp` and find the `from_srgb` stage. It'll look like
+
+<!--?prettify lang=cc?-->
+
+ STAGE(from_srgb) {
+ r = from_srgb(r);
+ g = from_srgb(g);
+ b = from_srgb(b);
+ }
+
+Let's replace whatever's there with our fast approximation:
+
+<!--?prettify lang=cc?-->
+
+ STAGE(from_srgb) {
+ r *= r;
+ g *= g;
+ b *= b;
+ }
+
+When you save and re-Ninja, you should now see changes to
+`src/jumper/SkJumper_generated.S` and `src/jumper/SkJumper_generated_win.S`.
+If you can't read assembly, no big deal. If you can, run `git diff`. You
+should see the various `sk_from_srgb_*` functions get dramatically simpler,
+something like three multiplies and a couple other bookkeeping instructions.
+
+It's not unusual for isolated changes in one stage to cause seemingly unrelated
+changes in another. When adding or removing any code you'll usually see all
+the comments in branch instructions change a little bit, but the actual
+instruction on the left won't change. When adding or removing uses of
+constants, you'll often see both the comment and instruction on the left change
+for other loads of constants from memory, especially on x86-64. You'll also
+see some code that looks like garbage change; those are the constants. If
+any of this worries you, please do go running to someone who knows more for
+help, but odds are everything is fine.
+
+At this point things should just be business as usual. Any time you change
+`SkJumper_stages.cpp`, Ninja ought to notice and regenerate the assembly files.
+
+Adding a new Stage
+------------------
+
+Adding a new stage is a lot like changing an existing stage. Edit
+`SkJumper_stages.cpp`, build Skia, test, repeat until correct.
+
+You'll just need to also edit `SkRasterPipeline.h` to add your new stage to the
+macro listing all the stages. The stage name is the handle normal Skia code
+uses to refer to the stage abstractly, and the wiring between
+`SkRasterPipeline::foo` and `STAGE(foo) { ... }` should work automatically.
diff --git a/src/third_party/skia/site/dev/contrib/patch.md b/src/third_party/skia/site/dev/contrib/patch.md
new file mode 100644
index 0000000..cf8b35b
--- /dev/null
+++ b/src/third_party/skia/site/dev/contrib/patch.md
@@ -0,0 +1,72 @@
+Applying patches
+================
+
+If you are a Skia committer and have been asked to commit an
+externally-submitted patch, this is how to do it. (This technique is useful in
+other situations too, like if you just want to try out somebody else's patch
+locally.)
+
+Notes:
+ * For the examples below, we will assume that this is the change you want
+ to patch into your local checkout: https://codereview.appspot.com/6201055/
+ * These instructions should work on Mac or Linux; Windows is trickier,
+ because there is no standard Windows "patch" tool.
+
+See also:
+http://dev.chromium.org/developers/contributing-code#TOC-Instructions-for-Reviewer:-Checking-in-the-patch-for-a-non-committer
+
+If you use git cl, then you should be able to use the shortcut:
+
+~~~~
+git cl patch 6201055
+~~~~
+
+If you use gcl, or the above doesn't work, the following should always work.
+
+1. Prepare your local workspace to accept the patch.
+
+ * cd into the root directory (usually trunk/) of the workspace where you
+ want to apply the patch.
+ * Make sure that the workspace is up-to-date and clean (or "updated and
+ clean enough" for your purposes). If the codereview patch was against
+ an old revision of the repo, you may need to sync your local workspace
+ to that same revision...
+
+2. Download the raw patch set.
+
+ * Open the codereview web page and look for the "Download raw patch set"
+ link near the upper right-hand corner. Right-click on that link and copy
+ it to the clipboard. (In my case, the link is
+ https://codereview.appspot.com/download/issue6201055_1.diff )
+ * If you are on Linux or Mac and have "curl" or "wget" installed, you can
+ download the patch from the command line:
+
+ ~~~~
+ curl https://codereview.appspot.com/download/issue6201055_1.diff
+ --output patch.txt
+ # or...
+ wget https://codereview.appspot.com/download/issue6201055_1.diff
+ --output-document=patch.txt
+ ~~~~
+
+ * Otherwise, figure out some other way to download this file and save it as
+ 'patch.txt'
+
+3. Apply this patch to your local checkout.
+
+ * You should still be in the root directory of the workspace where you want
+ to apply the patch.
+
+ ~~~~
+ patch -p1 <patch.txt
+ ~~~~
+
+ * Then you can run diff and visually check the local changes.
+
+4. Complications: If the patch fails to apply, the following may be happening:
+
+ Wrong revision. Maybe your local workspace is not up to date? Or maybe the
+ patch was made against an old revision of the repository, and cannot be applied
+ to the latest revision? (In that case, revert any changes and sync your
+ workspace to an older revision, then re-apply the patch.)
+
diff --git a/src/third_party/skia/site/dev/contrib/revert.md b/src/third_party/skia/site/dev/contrib/revert.md
new file mode 100644
index 0000000..75c4fcc
--- /dev/null
+++ b/src/third_party/skia/site/dev/contrib/revert.md
@@ -0,0 +1,39 @@
+How to revert a CL
+==================
+
+Using one-click revert
+----------------------
+* Find the codereview issue for the CL you want to revert.
+* Click the "revert" button.
+
+Using Git
+---------
+
+Update the local repository
+
+ git fetch origin master
+
+Create a local branch with origin/master as its start point.
+
+ git checkout -b revert$RANDOM origin/master
+
+Find the SHA1 of the commit you want to revert
+
+ git log origin/master
+
+Create a revert commit.
+
+ git revert <SHA1>
+
+Upload it to Gerrit.
+
+ git cl upload
+
+Land the revert in origin/master.
+
+ git cl land
+
+Delete the local revert branch.
+
+ git checkout --detach && git branch -D @{-1}
+
diff --git a/src/third_party/skia/site/dev/contrib/simd.md b/src/third_party/skia/site/dev/contrib/simd.md
new file mode 100644
index 0000000..e2e6310
--- /dev/null
+++ b/src/third_party/skia/site/dev/contrib/simd.md
@@ -0,0 +1,141 @@
+Skia's New Approach to SIMD
+===========================
+
+Most hot software paths in Skia are implemented with processor-specific SIMD instructions. For graphics performance, the parallelism from SIMD is essential: there is simply no realistic way to eek the same performance out of portable C++ code as we can from the SSE family of instruction sets on x86 or from NEON on ARM or from MIPS32's DSP instructions. Depending on the particular code path and math involved, we see 2, 4, 8, or even ~16x performance increases over portable code when really exploiting the processor-specific SIMD instructions.
+
+But the SIMD code we've piled up over the years has some serious problems. It's often quite low-level, with poor factoring leading to verbose, bug prone, and difficult to read code. SIMD instrinsic types and functions take a good long while to get used to reading, let alone writing, and assembly is generally just a complete non-starter. SIMD coverage of Skia methods is not dense: a particular drawing routine might be specialized for NEON but not for SSE, or might have a MIPS DSP implementation but no NEON. Even when we have full instruction set coverage, the implementations of these specialized routines may not produce identical results, either when compared with each other or with our portable fallback code. The SIMD implementations are often simply incorrect, but the code is so fragile and difficult to understand, we can't fix it. There are long lived bugs in our tracker involving crashes and buffer under- and overflows that we simply cannot fix because no one on the team understands the code involved. And finally, to top it all off, the code isn't always even really that fast.
+
+This all needs to change. I want Skia developers to be able to write correct, clear, and fast code, and in software rendering, SIMD is the only way to get "fast". This document outlines a new vision for how Skia will use SIMD instructions with no compromises, writing clear code _once_ that runs quickly on all platforms we support.
+
+The Plan
+--------
+
+We're going to wrap low-level platform-specific instrinsics with zero-cost abstractions with interfaces matching Skia's higher-level-but-still-quite-low-level use cases. Skia code will write to this interface _once_, which then compiles to efficient SSE, NEON, or portable code (MIPS is quite TBD, for now group it conceptually under portable code) via platform-specific backends. The key here is to find the right sweet spot of abstraction that allows us to express the graphical concepts we want in Skia while allowing each of those platform-specific backends flexibility to implement those concepts as efficiently as possible.
+
+While Skia uses a mix of float, 32-bit, 16-bit, and 8-bit integer SIMD instructions, 32-bit integers fall quite behind the rest in usage. Since we tend to operate on 8888 ARGB values, 8-bit SIMD tends to be the most natural and fastest approach, but when multiplication gets involved (essentially all the time), 16-bit SIMD inevitably gets tangled in there. For some operations like division, square roots, or math with high range or precision requirements, we expand our 8-bit pixel components up to floats, and working with a single pixel as a 4-float vector becomes most natural. This plan focuses on how we'll deal with these majority cases: floats, and 8- and 16-bit integers.
+
+`SkNf` for floats
+---------------
+
+Wrapping floats with an API that allows efficient implementation on SSE and NEON is by far the easiest task involved here. Both SSE and NEON naturally work with 128-bit vectors of 4 floats, and they have a near 1-to-1 correspondence between operations. Indeed, the correspondence is so close that it's tempting to solve this problem by picking one set of intrinsics, e.g. NEON, and just `#define`ing portable and SSE implementations of NEON:
+
+ #define float32x4_t __m128
+ #define vmulq_f32 _mm_mul_ps
+ #define vaddq_f32 _mm_add_ps
+ #define vld1q_f32 _mm_loadu_ps
+ #define vst1q_f32 _mm_storeu_ps
+ ...
+
+This temptation starts to break down when you notice:
+
+- there are operations that don't quite correspond, e.g. `_mm_movemask_ps`; and
+- math written with either SSE or NEON instrinsics is still very hard to read; and
+- sometimes we want to work with 4 floats, but sometimes 2, maybe even 8, etc.
+
+So we use a wrapper class `SkNf<N>`, parameterized on N, how many floats the vector contains, constrained at compile time to be a power of 2. `SkNf` provides all the methods you'd expect on vector of N floats: loading and storing from float arrays, all the usual arithmetic operators, min and max, low and high precision reciprocal and sqrt, all the usual comparison operators, and a `.thenElse()` method acting as a non-branching ternary `?:` operator. To support Skia's main graphic needs, `SkNf` can also load and store from a vector of N _bytes_, converting up to a float when loading and rounding down to [0,255] when storing.
+
+As a convenience, `SkNf<N>` has two default implementations: `SkNf<1>` performs all these operations on a single float, and the generic `SkNf<N>` simply recurses onto two `SkNf<N/2>`. This allows our different backends to inject specialiations where most natural: the portable backend does nothing, so all `SkNf<N>` recurse down to the default `SkNf<1>`; the NEON backend specializes `SkNf<2>` with `float32x2_t` and 64-bit SIMD methods, and `SkNf<4>` with `float32x4_t` and 128-bit SIMD methods; the SSE backend specializes both `SkNf<4>` and `SkNf<2>` to use the full or lower half of an `__m128` vector, respectively. A future AVX backend could simply drop in an `SkNf<8>` specialization.
+
+Our most common float use cases are working with 2D coordinates and with 4-float-component pixels. Since these are so common, we've made simple typedefs for these two use cases, `Sk2f` and `Sk4f`, and also versions reminding you that it can work with vectors of `SkScalar` (a Skia-specific float typedef) too: `Sk2s`, `Sk4s`.
+
+`SkNf` in practice
+----------------
+
+To date we have implemented several parts of Skia using Sk4f:
+
+ 1. `SkColorMatrixFilter`
+ 2. `SkRadialGradient`
+ 3. `SkColorCubeFilter`
+ 4. Three complicated `SkXfermode` subclasses: `ColorBurn`, `ColorDodge`, and `SoftLight`.
+
+In all these cases, we have been able to write a single implementation, producing the same results cross-platform. The first three of those sites using Sk4f are entirely newly vectorized, and run much faster than the previous portable implementations. The 3 Sk4f transfermodes replaced portable, SSE, and NEON implementations which all produced different results, and the Sk4f versions are all faster than their predecessors.
+
+`SkColorCubeFilter` stands out as a particularly good example of how and why to use Sk4f over custom platform-specific intrinsics. Starting from some portable code and a rather slow SSE-only sketch, a Google Chromium dev, an Intel contributor, and I worked together to write an Sk4f version that's more than twice as fast as the original, and runs fast on _both_ x86 and ARM.
+
+`SkPx` for 8- and 16-bit fixed point math
+----------------------------------------
+
+Building an abstraction layer over 8- and 16-bit fixed point math has proven to be quite a challenge. In fixed point, NEON and SSE again have some overlap, and they could probably be implemented in terms of each other if you were willing to sacrifice performance on SSE in favor of NEON or vice versa. But unlike with floats, where `SkNf` is really a pretty thin veneer over very similar operations, to really get the best performance out of each fixed point instruction set you need to work in rather different idioms.
+
+`SkPx`, our latest approach (there have been alpha `Sk16b` and beta `Sk4px` predecessors) to 8- and 16-bit SIMD tries to abstract over those idioms to again allow Skia developers to write one piece of clear graphics code that different backends can translate into their native intrinsics idiomatically.
+
+`SkPx` is really a family of three related types:
+
+ 1. `SkPx` itself represents between 1 and `SkPx::N` 8888 ARGB pixels, where `SkPx::N` is a backend-specific compile-time power of 2.
+ 2. `SkPx::Wide` represents those same pixels, but with 16-bits of space per component.
+ 3. `SkPx::Alpha` represents the alpha channels of those same pixels.
+
+`SkPx`, `Wide` and `Alpha` create a somewhat complicated algebra of operations entirely motivated by the graphical operations we need to perform. Here are some examples:
+
+ SkPx::LoadN(const uint32_t*) -> SkPx // Load full cruising-speed SkPx.
+ SkPx::Load(n, const uint32_t*) -> SkPx // For the 0<n<N ragged tail.
+
+ SkPx.storeN(uint32_t*) // Store a full SkPx.
+ SkPx.store(n, uint32_t*) // For the ragged 0<n<N tail.
+
+ SkPx + SkPx -> SkPx
+ SkPx - SkPx -> SkPx
+ SkPx.saturatedAdd(SkPx) -> SkPx
+
+ SkPx.alpha() -> Alpha // Extract alpha channels.
+ Alpha::LoadN(const uint8_t*) -> Alpha // Like SkPx loads, in 8-bit steps.
+ Alpha::Load(n, const uint8_t*) -> Alpha
+
+ SkPx.widenLo() -> Wide // argb -> 0a0r0g0b
+ SkPx.widenHi() -> Wide // argb -> a0r0g0b0
+ SkPx.widenLoHi() -> Wide // argb -> aarrggbb
+
+ Wide + Wide -> Wide
+ Wide - Wide -> Wide
+ Wide << bits -> Wide
+ Wide >> bits -> Wide
+
+ SkPx * Alpha -> Wide // 8 x 8 -> 16 bit
+ Wide.div255() -> SkPx // 16-bit -> 8 bit
+
+ // A faster approximation of (SkPx * Alpha).div255().
+ SkPx.approxMulDiv255(Alpha) -> SkPx
+
+We allow each `SkPx` backend to choose how it physically represents `SkPx`, `SkPx::Wide`, and `SkPx::Alpha` and to choose any power of two as its `SkPx::N` sweet spot. Code working with SkPx typically runs a loop like this:
+
+ while (n >= SkPx::N) {
+ // Apply some_function() to SkPx::N pixels.
+ some_function(SkPx::LoadN(src), SkPx::LoadN(dst)).storeN(dst);
+ src += SkPx::N; dst += SkPx::N; n -= SkPx::N;
+ }
+ if (n > 0) {
+ // Finish up the tail of 0<n<N pixels.
+ some_function(SkPx::Load(n, src), SkPx::Load(n, dst)).store(n, dst);
+ }
+
+The portable code is of course the simplest place to start looking at implementation details: its `SkPx` is just `uint8_t[4]`, its `SkPx::Wide` `uint16_t[4]`, and its `SkPx::Alpha` just `uint8_t`. Its preferred number of pixels to work with is `SkPx::N = 1`. (Amusingly, GCC and Clang seem pretty good about autovectorizing this backend using 32-bit math, which typically ends up within ~2x of the best we can do ourselves.)
+
+The most important difference between SSE and NEON when working in fixed point is that SSE works most naturally with 4 interlaced pixels at a time (argbargbargbargb), while NEON works most naturally with 8 planar pixels at a time (aaaaaaaa, rrrrrrrr, gggggggg, bbbbbbbb). Trying to jam one of these instruction sets into the other's idiom ends up somewhere between not quite optimal (working with interlaced pixels in NEON) and ridiculously inefficient (trying to work with planar pixels in SSE).
+
+So `SkPx`'s SSE backend sets N to 4 pixels, stores them interlaced in an `__m128i`, representing `Wide` as two `__m128i` and `Alpha` as an `__m128i` with each pixel's alpha component replicated four times. SkPx's NEON backend works with 8 planar pixels, loading them with `vld4_u8` into an `uint8x8x4_t` struct of 4 8-component `uint8x8_t` planes. `Alpha` is just a single `uint8x8_t` 8-component plane, and `Wide` is NEON's natural choice, `uint16x8x4_t`.
+
+(It's fun to speculate what an AVX2 backend might look like. Do we make `SkPx` declare it wants to work with 8 pixels at a time, or leave it at 4? Does `SkPx` become `__m256i`, or maybe only `SkPx::Wide` does? What's the best way to represent `Alpha`? And of course, what about AVX-512?)
+
+Keeping `Alpha` as a single dense `uint8x8_t` plane allows the NEON backend to be much more efficient with operations involving `Alpha`. We'd love to do this in SSE too, where we store `Alpha` somewhat inefficiently with each alpha component replicated 4 times, but SSE simply doesn't expose efficient ways to transpose interlaced pixels into planar pixels and vice versa. We could write them ourselves, but only as rather complex compound operations that slow things down more than they help.
+
+These details will inevitably change over time. The important takeaway here is, to really work at peak throughput in SIMD fixed point, you need to work with the idiom of the instruction set, and `SkPx` is a design that can present a consistent interface to abstract away backend details for you.
+
+`SkPx` in practice
+----------------
+
+I am in the process of rolling out `SkPx`. Some Skia code is already using its precursor, `Sk4px`, which is a bit like `SkPx` that forces `N=4` and restricts the layout to always use interlaced pixels: i.e. fine for SSE, not great for NEON.
+
+ 1. All ~20 other `SkXfermode` subclasses that are not implemented with `SkNf`.
+ 2. SkBlitRow::Color32
+ 3. SkBlitMask::BlitColor
+
+I can certainly say that the `Sk4px` and `SkPx` implementations of these methods are clearer, less buggy, and that all the `SkXfermode` implementations sped up at least 2x when porting from custom per-platform intrinsics. `Sk4px` has lead to some pretty bad performance regressions that `SkPx` is designed to avoid. This is an area of active experiementation and iteration.
+
+In Summary
+----------
+
+I am confident that Skia developers soon will be able to write single, clear, maintainable, and of course _fast_, graphical algorithms using `SkNf` and `SkPx`. As I have been porting our algorithms, I have perversely enjoyed replacing thousands of lines of unmaintainable code with usually mere dozens of readable code.
+
+I'm also confident that if you're looking to use floats, `SkNf` is ready. Do not write NEON or SSE SIMD code if you're looking to use floats, and do not accept external contributions that do so. Use `SkNf` instead.
+
+`SkPx` is less proven, and while its design and early tests look promising, it's still at the stage where we should try it aware that we might need to fall back on hand-written SSE or NEON.
\ No newline at end of file
diff --git a/src/third_party/skia/site/dev/contrib/style.md b/src/third_party/skia/site/dev/contrib/style.md
new file mode 100644
index 0000000..639738c
--- /dev/null
+++ b/src/third_party/skia/site/dev/contrib/style.md
@@ -0,0 +1,552 @@
+Coding Style Guidelines
+=======================
+
+These conventions have evolved over time. Some of the earlier code in both
+projects doesn’t strictly adhere to the guidelines. However, as the code evolves
+we hope to make the existing code conform to the guildelines.
+
+Files
+-----
+
+We use .cpp and .h as extensions for c++ source and header files. We use
+foo_impl.h for headers with inline definitions for class foo.
+
+Headers that aren’t meant for public consumption should be placed in src
+directories so that they aren’t in a client’s search path.
+
+We prefer to minimize includes. If forward declaring a name in a header is
+sufficient then that is preferred to an include.
+
+Forward declarations and file includes should be in alphabetical order (but we
+aren't very strict about it).
+
+<span id="no-define-before-sktypes"></span>
+Do not use #if/#ifdef before including "SkTypes.h" (directly or indirectly).
+
+We use spaces not tabs (4 of them).
+
+We use Unix style endlines (LF).
+
+We prefer no trailing whitespace but aren't very strict about it.
+
+We wrap lines at 100 columns unless it is excessively ugly (use your judgement).
+The soft line length limit was changed from 80 to 100 columns in June 2012. Thus,
+most files still adhere to the 80 column limit. It is not necessary or worth
+significant effort to promote 80 column wrapped files to 100 columns. Please
+don't willy-nilly insert longer lines in 80 column wrapped files. Either be
+consistent with the surrounding code or, if you really feel the need, promote
+the surrounding code to 100 column wrapping.
+
+Naming
+------
+
+Both projects use a prefix to designate that they are Skia prefix for classes,
+enums, structs, typedefs etc is Sk. Ganesh’s is Gr. Nested types should not be
+prefixed.
+
+<!--?prettify?-->
+~~~~
+class SkClass {
+public:
+ class HelperClass {
+ ...
+ };
+};
+~~~~
+
+Data fields in structs, classes, unions begin with lowercase f and are then
+camel capped.
+
+<!--?prettify?-->
+~~~~
+struct GrCar {
+ ...
+ float fMilesDriven;
+ ...
+};
+~~~~
+
+Globals variables are similar but prefixed with g and camel-capped
+
+<!--?prettify?-->
+~~~~
+bool gLoggingEnabled
+Local variables begin lowercases and are camel-capped.
+
+int herdCats(const Array& cats) {
+ int numCats = cats.count();
+}
+~~~~
+
+Enum values are prefixed with k. Unscoped enum values are post fixed with
+an underscore and singular name of the enum name. The enum itself should be
+singular for exclusive values or plural for a bitfield. If a count is needed it
+is k<singular enum name>Count and not be a member of the enum (see example):
+
+<!--?prettify?-->
+~~~~
+enum class SkPancakeType {
+ kBlueberry,
+ kPlain,
+ kChocolateChip,
+};
+~~~~
+
+<!--?prettify?-->
+~~~~
+enum SkPancakeType {
+ kBlueberry_PancakeType,
+ kPlain_PancakeType,
+ kChocolateChip_PancakeType,
+
+ kLast_PancakeType = kChocolateChip_PancakeType
+};
+
+static const SkPancakeType kPancakeTypeCount = kLast_PancakeType + 1;
+~~~~
+
+A bitfield:
+
+<!--?prettify?-->
+~~~~
+enum SkSausageIngredientBits {
+ kFennel_SuasageIngredientBit = 0x1,
+ kBeef_SausageIngredientBit = 0x2
+};
+~~~~
+
+or:
+
+<!--?prettify?-->
+~~~~
+enum SkMatrixFlags {
+ kTranslate_MatrixFlag = 0x1,
+ kRotate_MatrixFlag = 0x2
+};
+~~~~
+
+Exception: anonymous enums can be used to declare integral constants, e.g.:
+
+<!--?prettify?-->
+~~~~
+enum { kFavoriteNumber = 7 };
+~~~~
+
+Macros are all caps with underscores between words. Macros that have greater
+than file scope should be prefixed SK or GR.
+
+Static non-class functions in implementation files are lower case with
+underscores separating words:
+
+<!--?prettify?-->
+~~~~
+static inline bool tastes_like_chicken(Food food) {
+ return kIceCream_Food != food;
+}
+~~~~
+
+Externed functions or static class functions are camel-capped with an initial cap:
+
+<!--?prettify?-->
+~~~~
+bool SkIsOdd(int n);
+
+class SkFoo {
+public:
+ static int FooInstanceCount();
+};
+~~~~
+
+Macros
+------
+
+Ganesh macros that are GL-specific should be prefixed GR_GL.
+
+<!--?prettify?-->
+~~~~
+#define GR_GL_TEXTURE0 0xdeadbeef
+~~~~
+
+Ganesh prefers that macros are always defined and the use of #if MACRO rather than
+#ifdef MACRO.
+
+<!--?prettify?-->
+~~~~
+#define GR_GO_SLOWER 0
+...
+#if GR_GO_SLOWER
+ Sleep(1000);
+#endif
+~~~~
+
+Skia tends to use #ifdef SK_MACRO for boolean flags.
+
+Braces
+------
+
+Open braces don’t get a newline. “else” and “else if” appear on same line as
+opening and closing braces unless preprocessor conditional compilation
+interferes. Braces are always used with if, else, while, for, and do.
+
+<!--?prettify?-->
+~~~~
+if (...) {
+ oneOrManyLines;
+}
+
+if (...) {
+ oneOrManyLines;
+} else if (...) {
+ oneOrManyLines;
+} else {
+ oneOrManyLines;
+}
+
+for (...) {
+ oneOrManyLines;
+}
+
+while (...) {
+ oneOrManyLines;
+}
+
+void function(...) {
+ oneOrManyLines;
+}
+
+if (!error) {
+ proceed_as_usual();
+}
+#if HANDLE_ERROR
+else {
+ freak_out();
+}
+#endif
+~~~~
+
+Flow Control
+------------
+
+There is a space between flow control words and parentheses and between
+parentheses and braces:
+
+<!--?prettify?-->
+~~~~
+while (...) {
+}
+
+do {
+} while(...);
+
+switch (...) {
+...
+}
+~~~~
+
+Cases and default in switch statements are indented from the switch.
+
+<!--?prettify?-->
+~~~~
+switch (color) {
+ case kBlue:
+ ...
+ break;
+ case kGreen:
+ ...
+ break;
+ ...
+ default:
+ ...
+ break;
+}
+~~~~
+
+Fallthrough from one case to the next is commented unless it is trivial:
+
+<!--?prettify?-->
+~~~~
+switch (recipe) {
+ ...
+ case kCheeseOmelette_Recipe:
+ ingredients |= kCheese_Ingredient;
+ // fallthrough
+ case kPlainOmelette_Recipe:
+ ingredients |= (kEgg_Ingredient | kMilk_Ingredient);
+ break;
+ ...
+}
+~~~~
+
+When a block is needed to declare variables within a case follow this pattern:
+
+<!--?prettify?-->
+~~~~
+switch (filter) {
+ ...
+ case kGaussian_Filter: {
+ Bitmap srcCopy = src->makeCopy();
+ ...
+ break;
+ }
+ ...
+};
+~~~~
+
+Classes
+-------
+
+Unless there is a need for forward declaring something, class declarations
+should be ordered public, protected, private. Each should be preceded by a
+newline. Within each visibility section (public, private), fields should not be
+intermixed with methods.
+
+<!--?prettify?-->
+~~~~
+class SkFoo {
+
+public:
+ ...
+
+protected:
+ ...
+
+private:
+ SkBar fBar;
+ ...
+
+ void barHelper(...);
+ ...
+};
+~~~~
+
+Subclasses should have a private typedef of their super class called INHERITED:
+
+<!--?prettify?-->
+~~~~
+class GrDillPickle : public GrPickle {
+ ...
+private:
+ typedef GrPickle INHERITED;
+};
+~~~~
+
+Virtual functions that are overridden in derived classes should use override
+(and not the override keyword). The virtual keyword can be omitted.
+
+<!--?prettify?-->
+~~~~
+void myVirtual() override {
+}
+~~~~
+
+This should be the last element of their private section, and all references to
+base-class implementations of a virtual function should be explicitly qualified:
+
+<!--?prettify?-->
+~~~~
+void myVirtual() override {
+ ...
+ this->INHERITED::myVirtual();
+ ...
+}
+~~~~
+
+As in the above example, derived classes that redefine virtual functions should
+use override to note that explicitly.
+
+Constructor initializers should be one per line, indented, with punctuation
+placed before the initializer. This is a fairly new rule so much of the existing
+code is non-conforming. Please fix as you go!
+
+<!--?prettify?-->
+~~~~
+GrDillPickle::GrDillPickle()
+ : GrPickle()
+ , fSize(kDefaultPickleSize) {
+ ...
+}
+~~~~
+
+Constructors that take one argument should almost always be explicit, with
+exceptions made only for the (rare) automatic compatibility class.
+
+<!--?prettify?-->
+~~~~
+class Foo {
+ explicit Foo(int x); // Good.
+ Foo(float y); // Spooky implicit conversion from float to Foo. No no no!
+ ...
+};
+~~~~
+
+Method calls within method calls should be prefixed with dereference of the
+'this' pointer. For example:
+
+<!--?prettify?-->
+~~~~
+this->method();
+~~~~
+
+Comparisons
+-----------
+
+We prefer that equality operators between lvalues and rvalues place the lvalue
+on the right:
+
+<!--?prettify?-->
+~~~~
+if (7 == luckyNumber) {
+ ...
+}
+~~~~
+
+However, inequality operators need not follow this rule:
+
+<!--?prettify?-->
+~~~~
+if (count > 0) {
+ ...
+}
+~~~~
+
+Comments
+
+We use doxygen-style comments.
+
+For grouping or separators in an implementation file we use 80 slashes
+
+<!--?prettify?-->
+~~~~
+void SkClassA::foo() {
+ ...
+}
+
+////////////////////////////////////////////////////////////////
+
+void SkClassB::bar() {
+ ...
+}
+~~~~
+
+Integer Types
+-------------
+
+We follow the Google C++ guide for ints and are slowly making older code conform to this
+
+(http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Integer_Types)
+
+Summary: Use int unless you have need a guarantee on the bit count, then use
+stdint.h types (int32_t, etc). Assert that counts, etc are not negative instead
+of using unsigned. Bitfields use uint32_t unless they have to be made shorter
+for packing or performance reasons.
+
+nullptr, 0
+-------
+
+Use nullptr for pointers, 0 for ints. We prefer explicit nullptr comparisons when
+checking for nullptr pointers (as documentation):
+
+<!--?prettify?-->
+~~~~
+if (nullptr == x) { // slightly preferred over if (!x)
+ ...
+}
+~~~~
+
+When checking non-nullptr pointers explicit comparisons are not required because it
+reads like a double negative:
+
+<!--?prettify?-->
+~~~~
+if (x) { // slightly preferred over if (nullptr != x)
+ ...
+}
+~~~~
+
+Returning structs
+-----------------
+
+If the desired behavior is for a function to return a struct, we prefer using a
+struct as an output parameter
+
+<!--?prettify?-->
+~~~~
+void modify_foo(SkFoo* foo) {
+ // Modify foo
+}
+~~~~
+
+Then the function can be called as followed:
+
+<!--?prettify?-->
+~~~~
+SkFoo foo;
+modify_foo(&foo);
+~~~~
+
+This way, if return value optimization cannot be used there is no performance
+hit. It also means that modify_foo can actually return a boolean for whether the
+call was successful. In this case, initialization of foo can potentially be
+skipped on failure (assuming the constructor for SkFoo does no initialization).
+
+<!--?prettify?-->
+~~~~
+bool modify_foo(SkFoo* foo) {
+ if (some_condition) {
+ // Modify foo
+ return true;
+ }
+ // Leave foo unmodified
+ return false;
+}
+~~~~
+
+Function Parameters
+-------------------
+
+Mandatory constant object parameters are passed to functions as const references
+if they are not retained by the receiving function. Optional constant object
+parameters are passed to functions as const pointers. Objects that the called
+function will retain, either directly or indirectly, are passed as pointers.
+Variable (i.e. mutable) object parameters are passed to functions as pointers.
+
+<!--?prettify?-->
+~~~~
+// src and paint are optional
+void SkCanvas::drawBitmapRect(const SkBitmap& bitmap, const SkIRect* src,
+ const SkRect& dst, const SkPaint* paint = nullptr);
+// metrics is mutable (it is changed by the method)
+SkScalar SkPaint::getFontMetrics(FontMetric* metrics, SkScalar scale) const;
+// A reference to foo is retained by SkContainer
+void SkContainer::insert(const SkFoo* foo);
+~~~~
+
+If function arguments or parameters do not all fit on one line, they may be
+lined up with the first parameter on the same line
+
+<!--?prettify?-->
+~~~~
+void drawBitmapRect(const SkBitmap& bitmap, const SkRect& dst,
+ const SkPaint* paint = nullptr) {
+ this->drawBitmapRectToRect(bitmap, nullptr, dst, paint,
+ kNone_DrawBitmapRectFlag);
+}
+~~~~
+
+or placed on the next line indented eight spaces
+
+<!--?prettify?-->
+~~~~
+void drawBitmapRect(
+ const SkBitmap& bitmap, const SkRect& dst,
+ const SkPaint* paint = nullptr) {
+ this->drawBitmapRectToRect(
+ bitmap, nullptr, dst, paint, kNone_DrawBitmapRectFlag);
+}
+~~~~
+
+Python
+------
+
+Python code follows the [Google Python Style Guide](http://google-styleguide.googlecode.com/svn/trunk/pyguide.html).
+
diff --git a/src/third_party/skia/site/dev/contrib/submit.md b/src/third_party/skia/site/dev/contrib/submit.md
new file mode 100644
index 0000000..d3ffc9d
--- /dev/null
+++ b/src/third_party/skia/site/dev/contrib/submit.md
@@ -0,0 +1,211 @@
+How to submit a patch
+=====================
+
+
+Configure git
+-------------
+
+<!--?prettify lang=sh?-->
+
+ git config --global user.name "Your Name"
+ git config --global user.email you@example.com
+
+Making changes
+--------------
+
+First create a branch for your changes:
+
+<!--?prettify lang=sh?-->
+
+ git config branch.autosetuprebase always
+ git checkout -b my_feature origin/master
+
+After making your changes, create a commit
+
+<!--?prettify lang=sh?-->
+
+ git add [file1] [file2] ...
+ git commit
+
+If your branch gets out of date, you will need to update it:
+
+<!--?prettify lang=sh?-->
+
+ git pull
+ python tools/git-sync-deps
+
+Adding a unit test
+------------------
+
+If you are willing to change Skia codebase, it's nice to add a test at the same
+time. Skia has a simple unittest framework so you can add a case to it.
+
+Test code is located under the 'tests' directory.
+
+See [Writing Unit and Rendering Tests](../testing/tests) for details.
+
+Unit tests are best, but if your change touches rendering and you can't think of
+an automated way to verify the results, consider writing a GM test or a new page
+of SampleApp. Also, if your change is the GPU code, you may not be able to write
+it as part of the standard unit test suite, but there are GPU-specific testing
+paths you can extend.
+
+Submitting a patch
+------------------
+
+For your code to be accepted into the codebase, you must complete the
+[Individual Contributor License
+Agreement](http://code.google.com/legal/individual-cla-v1.0.html). You can do
+this online, and it only takes a minute. If you are contributing on behalf of a
+corporation, you must fill out the [Corporate Contributor License
+Agreement](http://code.google.com/legal/corporate-cla-v1.0.html)
+and send it to us as described on that page. Add your (or your organization's)
+name and contact info to the AUTHORS file as a part of your CL.
+
+Now that you've made a change and written a test for it, it's ready for the code
+review! Submit a patch and getting it reviewed is fairly easy with depot tools.
+
+Use git-cl, which comes with [depot
+tools](http://sites.google.com/a/chromium.org/dev/developers/how-tos/install-depot-tools).
+For help, run git-cl help.
+
+### Find a reviewer
+
+Ideally, the reviewer is someone who is familiar with the area of code you are
+touching. If you have doubts, look at the git blame for the file to see who else
+has been editing it.
+
+### Uploading changes for review
+
+Skia uses the Gerrit code review tool. Skia's instance is [skia-review](http://skia-review.googlesource.com).
+Use git cl to upload your change:
+
+<!--?prettify lang=sh?-->
+
+ git cl upload
+
+You may have to enter a Google Account username and password to authenticate
+yourself to Gerrit. A free gmail account will do fine, or any
+other type of Google account. It does not have to match the email address you
+configured using `git config --global user.email` above, but it can.
+
+The command output should include a URL, similar to
+(https://skia-review.googlesource.com/c/4559/), indicating where your changelist
+can be reviewed.
+
+### Request review
+
+Go to the supplied URL or go to the code review page and select the **Your**
+dropdown and click on **Changes**. Select the change you want to submit for
+review and click **Reply**. Enter at least one reviewer's email address. Now
+add any optional notes, and send your change off for review by clicking on
+**Send**. Unless you send your change to reviewers, no one will know to look
+at it.
+
+_Note_: If you don't see editing commands on the review page, click **Sign in**
+in the upper right. _Hint_: You can add -r reviewer@example.com --send-mail to
+send the email directly when uploading a change using git-cl.
+
+
+The review process
+------------------
+
+If you submit a giant patch, or do a bunch of work without discussing it with
+the relevant people, you may have a hard time convincing anyone to review it!
+
+Code reviews are an important part of the engineering process. The reviewer will
+almost always have suggestions or style fixes for you, and it's important not to
+take such suggestions personally or as a commentary on your abilities or ideas.
+This is a process where we work together to make sure that the highest quality
+code gets submitted!
+
+You will likely get email back from the reviewer with comments. Fix these and
+update the patch set in the issue by uploading again. The upload will explain
+that it is updating the current CL and ask you for a message explaining the
+change. Be sure to respond to all comments before you request review of an
+update.
+
+If you need to update code the code on an already uploaded CL, simply edit the
+code, commit it again locally, and then run git cl upload again e.g.
+
+ echo "GOATS" > whitespace.txt
+ git add whitespace.txt
+ git commit -m 'add GOATS fix to whitespace.txt'
+ git cl upload
+
+Once you're ready for another review, use **Reply** again to send another
+notification (it is helpful to tell the review what you did with respect to each
+of their comments). When the reviewer is happy with your patch, they will
+approve your change by setting the Code-Review label to "+1".
+
+_Note_: As you work through the review process, both you and your reviewers
+should converse using the code review interface, and send notes.
+
+Once your change has received an approval, you can click the "Submit to CQ"
+button on the codereview page and it will be committed on your behalf.
+
+Once your commit has gone in, you should delete the branch containing your change:
+
+ git checkout -q origin/master
+ git branch -D my_feature
+
+
+Final Testing
+-------------
+
+Skia's principal downstream user is Chromium, and any change to Skia rendering
+output can break Chromium. If your change alters rendering in any way, you are
+expected to test for and alleviate this. (You may be able to find a Skia team
+member to help you, but the onus remains on each individual contributor to avoid
+breaking Chrome.
+
+### Evaluating Impact on Chromium
+
+Keep in mind that Skia is rolled daily into Blink and Chromium. Run local tests
+and watch canary bots for results to ensure no impact. If you are submitting
+changes that will impact layout tests, follow the guides below and/or work with
+your friendly Skia-Blink engineer to evaluate, rebaseline, and land your
+changes.
+
+Resources:
+
+[How to land Skia changes that change Blink layout test results](../chrome/layouttest)
+
+If you're changing the Skia API, you may need to make an associated change in Chromium.
+If you do, please follow these instructions: [Landing Skia changes which require Chrome changes](../chrome/changes)
+
+
+Check in your changes
+---------------------
+
+### Non-Skia-committers
+
+If you already have committer rights, you can follow the directions below to
+commit your change directly to Skia's repository.
+
+If you don't have committer rights in https://skia.googlesource.com/skia.git ...
+first of all, thanks for submitting your patch! We really appreciate these
+submissions. After receiving an approval from a committer, you will be able to
+click the "Submit to CQ" button and submit your patch via the commit queue.
+
+In special instances, a Skia committer may assist you in landing the change
+by uploading a new codereview containing your patch (perhaps with some small
+adjustments at his/her discretion). If so, you can mark your change as
+"Abandoned", and update it with a link to the new codereview.
+
+### Skia committers
+ * tips on how to apply an externally provided patch are [here](./patch)
+ * when landing externally contributed patches, please note the original
+ contributor's identity (and provide a link to the original codereview) in the commit message
+
+ git-cl will squash all your commits into a single one with the description you used when you uploaded your change.
+
+ ~~~~
+ git cl land
+ ~~~~
+
+ or
+
+ ~~~~
+ git cl land -c 'Contributor Name <email@example.com>'
+ ~~~~
