Should make it easier to ask just for images.
Change-Id: If821743dc924c4bfbc6b2b2d29b14affde7b3afd
Reviewed-on: https://skia-review.googlesource.com/82684
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Bug: skia:
Change-Id: I79d0b0707b09a3eedeeaee940d6dafbbbdbe2fe2
Reviewed-on: https://skia-review.googlesource.com/17707
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Reed <reed@google.com>
I was using SkRect::MakeLargest() as bounds, which is sort of nutso,
as that clearly is way out of bounds for how big a picture can feasibly
be, i.e. something closer to SkIRect::MakeLargest().
This was causing spurious quick rejects in drawPatch(). I didn't really
look much deeper to figure out why. It's easy enough to just feed it the
proper bounds of the entire content.
This means patch_primitive draws correctly in sp-8888 mode.
I also noticed the GM was too small... it clipped off most of its content.
So I've made it larger.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1865143002
Review URL: https://codereview.chromium.org/1865143002
I have verified locally that nothing draws differently.
Motivation:
* SK_SIMPLE_GM makes it easier to write a GM.
* Reducing 1100 lines of code makes maintenance easier.
* Simple GMs are easy to convert to Fiddles.
Review URL: https://codereview.chromium.org/1333553002
This fixes every case where virtual and SK_OVERRIDE were on the same line,
which should be the bulk of cases. We'll have to manually clean up the rest
over time unless I level up in regexes.
for f in (find . -type f); perl -p -i -e 's/virtual (.*)SK_OVERRIDE/\1SK_OVERRIDE/g' $f; end
BUG=skia:
Review URL: https://codereview.chromium.org/806653007
patches and uses 4 private arrays to store the values of the control points and
colors. When it needs a patch at a certain position of the grid it just
builds it using the corresponding values of the array and the
grid coordinates provided. Details on implementation are documented in the corresponding classes' comments.
Also added a gm for mesh gradients.
BUG=skia:
R=egdaniel@google.com, reed@google.com
Author: dandov@google.com
Review URL: https://codereview.chromium.org/451723003
drawPatch now receives as parameter const SkPoint cubics[12]
Adjusted derived classes and serialization.
Ajusted GM's and benches that take into account combinations of optional
parameters, the scale of the patch and 4 different types of patches.
Planning on adding the extra functionality of SkPatch in another CL.
BUG=skia:
R=egdaniel@google.com, reed@google.com
Author: dandov@google.com
Review URL: https://codereview.chromium.org/463493002
Added function SkCanvas::drawPatch to the API. This function
receives the patch to draw and the paint.
Added function SkBaseDevice::drawPatch to the API. This function also receives the patch to draw and the paint.
Currently SkGpuDevice and SkBitmapDevice generate the mesh taking into
account the scale factor and call the corresponding device's drawVertices.
BUG=skia:
R=jvanverth@google.com, egdaniel@google.com, bsalomon@google.com
Author: dandov@google.com
Review URL: https://codereview.chromium.org/424663006
Each patch defines a method genMesh that produces the geometry to draw. To do this they receive a SkPatchMesh object which they need to initialize in order to set up how the data is going to be formatted. Later they call function like setColor or pointAt to set the values at a specific index, the SkMeshPatch object handles the indices based on the format and makes it transparent to the client.
Added a slide to sample app to show how to set up this classes and how they interact.
BUG=skia:
R=jvanverth@google.com, egdaniel@google.com, bsalomon@google.com
Author: dandov@google.com
Review URL: https://codereview.chromium.org/405163003
