Having the picture contents not actually reside in the 0,0..W,H range wrecks havoc with the layer hoisting. The hoisting works correctly but since the picture don't fulfill their contract the results look incorrect.
This CL just translates the picture's contents to the right so they are within the picture bound.
R=egdaniel@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/594363003
Scale all images to the nearest rounded integer, and if there's still
any scaling factor left over, pass it on to the subsequent bilerp code.
Should avoid artifacts when tiling scaled images.
Original CL received an LGTM from reed; new version disabled tiling
in the downsamplebitmap GM; I verified that this fixes the issue
we were seeing there on non-neon androids.
BUG=skia:2888
R=reed@android.com
TBR=reed
Author: humper@google.com
Review URL: https://codereview.chromium.org/514383003
Without this change, SKP tests *appeared* to fail because the actuals reported
their checksumValues as integers, while the expectations recorded their
checksumValues as strings.
NOTREECHECKS=true
NOTRY=true
R=stephana@google.com
TBR=stephana
(SkipBuildbotRuns)
Author: epoger@google.com
Review URL: https://codereview.chromium.org/489023003
This will allow developers to maintain SKP baselines without ever running their
own rebaseline_server instance!
For now, the developer must manually apply the resulting patchset to his local
Skia checkout to actually modify expectations; in the near future, we hope to
make the UI upload the patchset to Rietveld on the user's behalf.
BUG=skia:1918
NOTRY=true
R=stephana@google.com, rmistry@google.com
Author: epoger@google.com
Review URL: https://codereview.chromium.org/487853004
This is needed for rebaselining using the shared rebaseline_server instance:
by telling the client which git revision was used to fetch expectations, we
allow the client to pass that back along with new baselines (so the server
knows which revision to patch).
This is also handy in that it allows the server to tell the client more about the
different result sets (which files they were generated from).
BUG=skia:1918
NOTRY=true
R=rmistry@google.com
Author: epoger@google.com
Review URL: https://codereview.chromium.org/474813002
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
This will allow the buildbots to warn the production rebaseline_server: "I just
generated some new results; here's a comparison that a human might ask for
soon. Download whatever images and generate whatever diffs you would need to
provide those results."
BUG=skia:1942
NOTREECHECKS=true
NOTRY=true
R=rmistry@google.com
Author: epoger@google.com
Review URL: https://codereview.chromium.org/443013002
This is a step towards providing SKP comparisons against expectations, not just
other actual results... we still need to allow the user to select
JSONKEY_EXPECTEDRESULTS vs JSONKEY_ACTUALRESULTS within the summary
files found.
BUG=skia:1942
NOTREECHECKS=true
NOTRY=true
R=rmistry@google.com
Author: epoger@google.com
Review URL: https://codereview.chromium.org/442203002
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
Allow GM results to be compared across machines and platforms by
standardizing the fonts used by all tests.
This adds runtime flags to DM to use either the system font context (the
default), the fonts in the resources directory ( --resourceFonts ) or a set
of canonical paths generated from the fonts ( --portableFonts ).
This CL should leave the current DM results unchanged by default.
If the portable font data or resource font is missing when DM is run, it
falls back to using the system font context.
The create_test_font tool generates the paths and metrics read by DM
with the --portableFonts flag set, and generates the font substitution
tables read by DM with the --resourceFonts flag set.
If DM is run in SkDebug mode with the --reportUsedChars flag set, it
generates the corresponding data compiled into the create_test_font tool.
All GM tests set their typeface information by calling either
sk_tool_utils::set_portable_typeface or
sk_tool_utils::portable_typeface .
(The former takes the paint, the latter returns a SkTypeface.) These calls
can be removed in the future when the Font Manager can be superceded.
BUG=skia:2687
R=mtklein@google.com
Review URL: https://codereview.chromium.org/407183003
Before this change, GrStencilAndCoverTextContext would send 6-float
affine transforms to drawPaths for every glyph. This updates it to
concat the text scale onto the context matrix, and then only send
2-float translates (or 1-float x-translates when possible).
Also adds a glyph_pos_align test to gm that exercises the newly added
codepaths, and starts ignoring a few gm tests with benign pixel diffs
until we can rebaseline.
BUG=skia:
R=bsalomon@google.com, kkinnunen@nvidia.com, jvanverth@google.com, bungeman@google.com
Author: cdalton@nvidia.com
Review URL: https://codereview.chromium.org/406523003
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
Replay isn't that helpful of a test any more now that we have the more
stringent Quilt tests. Quilt was missing bounding box hierarchies, though,
while Replay was sort of testing RTree (pointlessly, as it was drawing without
any clip). Now Quilt does everything, testing RTree, QuadTree, and TileGrid.
Quilt mode now falls back to drawing all at once (i.e. Replay) for GMs that
don't tile perfectly. Still a TODO to make this check more flexible than exact
pixel matches.
Two GMs fail when using a BBH:
- imageresizetiled
- resizeimagefilter
We think we're not adjusting the bounds of save layers by their paint.
This is probably a bug, but one to be fixed separately from adding new tests.
BUG=skia:
R=robertphillips@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/377373003
Rather than rebuilding the ImageDiffDB from scratch every time we update expected/actual results, keep the same ImageDiffDB instance around and add image pairs to it.
This makes updating results within a long-running server.py *much* faster, and tests out an idea I'm ruminating in https://goto.google.com/LongRunningImageDiffDBServer : we could run an ImageDiffDB server that developers could connect to from their locally running rebaseline_server instances, for much faster launch times.
BUG=skia:2414
NOTRY=True
R=rmistry@google.com
Author: epoger@google.com
Review URL: https://codereview.chromium.org/379563005
Makes the rebaseline_server client more generic, allowing the server to tweak display properties by writing directives into the JSON file.
Adds two new fields to the rebaseline_server JSON file (and thus increments VALUE__HEADER__SCHEMA_VERSION):
1. KEY__ROOT__EXTRACOLUMNORDER: order in which the client should display columns
2. KEY__EXTRACOLUMNHEADERS__USE_FREEFORM_FILTER: whether a column should be filtered using a freeform text field or checkboxes
BUG=skia:2230
NOTRY=True
R=rmistry@google.com
Author: epoger@google.com
Review URL: https://codereview.chromium.org/376623002
Now that all creation of SkImageFilters goes through
factory Create() methods, there's no real reason for the
convenience constructors. Some SkImageFilter subclasses
which actually have zero DAG-able inputs were passing NULL
to the superclass constructor. This actually means 1 input,
with a NULL value, not zero inputs. This becomes more
relevant for the upcoming cache infrastructure, where this
indicates that the filter will use its src input, where in
fact some of these filters do not (they are image generators
only).
Limiting SkImageFilter to a single constructor resolves this
ambiguity.
Along the way, I removed all of the default parameters to
the constructors, since the Create methods always call them
with the full argument list.
BUG=skia:
R=reed@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/376953003
This is a first piece of the GPU YUV decoder, which is the actual effect that performs the conversion. For now, it simply applies the conversion matrix, since it is all I need. I may add modes if different matrices need to be applied or if I add color profile support here.
I'll try to keep these cls short and easy to review, but there should be a few of them coming once this one is in.
BUG=skia:
R=senorblanco@chromium.org, senorblanco@google.com, reed@google.com, bsalomon@google.com
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/378503006
Now that we're drawing tiles threaded like implside painting, remove the checks
that those lock counts are balanced. They're just not right for anyone anymore.
SkBitmaps themselves are not threadsafe (even const ones), so shallow copy them
on playback of an SkRecord. (The underlying SkPixelRefs are threadsafe.)
Simplify quilt drawing by using SkBitmap::extractSubset. No need for locking.
Bump up to 256x256 tiles. 16x16 tiles just murders performance (way too much
contention). This has the nice side effect of letting us enable a bunch more
GMs for quilt mode; they drew wrong with small tiles but exactly right with large.
BUG=171776
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/371023005
In https://codereview.chromium.org/369473005 ('rebaseline_server: handle category filtering more generically'), I am changing the meaning of some URL parameters. If a user pastes an old URL into an updated rebaseline_server instance, they may get unexpected results. Adding a urlSchemaVersion parameter allows us to automatically convert the URL, or at least warn the user.
BUG=skia:2230
NOTRY=True
R=jcgregorio@google.com
Author: epoger@google.com
Review URL: https://codereview.chromium.org/368933002
Reason for revert:
Rebaseline CL is ready to be submitted
Original issue's description:
> Revert of Fix SkPaint::measureText for stroked hairline text (https://codereview.chromium.org/335603003/)
>
> Reason for revert:
> Caused many shadertext GM failures
>
> Original issue's description:
> > Fix SkPaint::measureText for stroked hairline text
> >
> > SkPaint::measureText and text drawing used different criteria for
> > determining whether text should be drawn as paths or not.
> >
> > Adds tests glyph_pos_(h/n)_(s/f/b) to test the text rendering and the glyph
> > positioning in the rendering. Mainly added in order to define what is the
> > expected text rendering when hairline stroke is used with various transform
> > options.
> >
> > The testcase also tries to note or highlight the fact that SkPaint::measureText
> > is not expected to produce intuitively matching results when compared to a
> > rendering, if the rendering is done so that the device ends up having a device
> > transform.
> >
> > This fixes the glyph_pos_h_s (hairline, stroked) test-case.
> >
> > Ignore shadertext2_pdf-poppler.png gm on
> > Test-Ubuntu13.10-ShuttleA-NoGPU-x86_64-Debug temporarily, as that fails.
> >
> > Committed: https://skia.googlesource.com/skia/+/196af738027c5e18c3eb792dbcaf90ef27821793
>
> TBR=jvanverth@google.com,reed@google.com,kkinnunen@nvidia.com
> NOTREECHECKS=true
> NOTRY=true
>
> Committed: https://skia.googlesource.com/skia/+/abc9bb55ddfeb4b1a7acc335a34841fddcd22d27R=jvanverth@google.com, reed@google.com, kkinnunen@nvidia.comTBR=jvanverth@google.com, kkinnunen@nvidia.com, reed@google.com
NOTREECHECKS=true
NOTRY=true
Author: rmistry@google.com
Review URL: https://codereview.chromium.org/349153005
Reason for revert:
Caused many shadertext GM failures
Original issue's description:
> Fix SkPaint::measureText for stroked hairline text
>
> SkPaint::measureText and text drawing used different criteria for
> determining whether text should be drawn as paths or not.
>
> Adds tests glyph_pos_(h/n)_(s/f/b) to test the text rendering and the glyph
> positioning in the rendering. Mainly added in order to define what is the
> expected text rendering when hairline stroke is used with various transform
> options.
>
> The testcase also tries to note or highlight the fact that SkPaint::measureText
> is not expected to produce intuitively matching results when compared to a
> rendering, if the rendering is done so that the device ends up having a device
> transform.
>
> This fixes the glyph_pos_h_s (hairline, stroked) test-case.
>
> Ignore shadertext2_pdf-poppler.png gm on
> Test-Ubuntu13.10-ShuttleA-NoGPU-x86_64-Debug temporarily, as that fails.
>
> Committed: https://skia.googlesource.com/skia/+/196af738027c5e18c3eb792dbcaf90ef27821793R=jvanverth@google.com, reed@google.com, kkinnunen@nvidia.comTBR=jvanverth@google.com, kkinnunen@nvidia.com, reed@google.com
NOTREECHECKS=true
NOTRY=true
Author: rmistry@google.com
Review URL: https://codereview.chromium.org/354433002
SkPaint::measureText and text drawing used different criteria for
determining whether text should be drawn as paths or not.
Adds tests glyph_pos_(h/n)_(s/f/b) to test the text rendering and the glyph
positioning in the rendering. Mainly added in order to define what is the
expected text rendering when hairline stroke is used with various transform
options.
The testcase also tries to note or highlight the fact that SkPaint::measureText
is not expected to produce intuitively matching results when compared to a
rendering, if the rendering is done so that the device ends up having a device
transform.
This fixes the glyph_pos_h_s (hairline, stroked) test-case.
Ignore shadertext2_pdf-poppler.png gm on
Test-Ubuntu13.10-ShuttleA-NoGPU-x86_64-Debug temporarily, as that fails.
R=jvanverth@google.com, reed@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/335603003
Always build the tools with JSON, but either build our own
or use the system's.
Rename skia_build_json_writer to skia_use_system_jsoncpp,
since we now always build with JSON.
Remove SK_BUILD_JSON_WRITER, which was only there so
we could build without JSON it in the framework.
BUG=skia:2448
R=djsollen@google.com, reed@google.com
Author: scroggo@google.com
Review URL: https://codereview.chromium.org/303913002
It turns out that the perlin implementation we inherited from WebKit
does not actually generate tileable noise (see Chromium bug
http://crbug.com/383495).
The main problem is that when generating coordinates for gradient
interpolation, it was attempting to wrap both x and (x + 1)
simultaneously at the tile boundary (that is, either both or neither
are wrapped). This obviously won't work, since along the tile seams,
(x + 1) should be wrapped, but x should not. The same is true in y.
This patch fixes both the CPU and GPU paths, renames some variables to
more closely match the spec, and modifies the perlin noise GM to
actually test tiling. (Note that the clipping the GM was doing was
removed, since it's superfluous: it used to be necessary for image
filters, but isn't anymore, and this isn't an image filter GM anyway.)
R=sugoi@google.com, sugoi
TBR=senorblanco
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/332523006
This will allow us to batch dashed lines together when drawing. Also, this removes the need for
a coord transform matrix in the shader, thus we save the cost of uploading a new matrix uniform
everytime we do a simple transform to the dashed line we are drawing.
BUG=skia:
R=bsalomon@google.com
Author: egdaniel@google.com
Review URL: https://codereview.chromium.org/326103002
