morphology, blur.
[Reland with fixed tests.]
Because we're computing "backwards" from a clip rect of destination
pixels to be filled to the required source pixels, we should use tail
recursion rather than head recursion in onFilterBounds().
This actually only makes a difference for drop-shadow, where
the computation is non-commutative. Blur and morphology commute, but I
moved them to tail recursion anyway for clarity (so all onFilterBounds
use tail recursion).
BUG=skia:
R=bsalomon@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/481273005
Reason for revert:
This CL is currently breaking the Win7 and Win8 bots on some of the new tests (in DM).
Original issue's description:
> Fix recursive computation of filter bounds for drop shadow,
> morphology, blur.
>
> Because we're computing "backwards" from a clip rect of destination
> pixels to be filled to the required source pixels, we should use tail
> recursion rather than head recursion in onFilterBounds().
>
> This actually only makes a difference for drop-shadow, where
> the computation is non-commutative. Blur and morphology commute, but I
> moved them to tail recursion anyway for clarity (so all onFilterBounds
> use tail recursion).
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/28648fe4a69b0cee8df42b5966e4e645c3aabefbR=bsalomon@google.com, senorblanco@chromium.orgTBR=bsalomon@google.com, senorblanco@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: djsollen@google.com
Review URL: https://codereview.chromium.org/504773003
morphology, blur.
Because we're computing "backwards" from a clip rect of destination
pixels to be filled to the required source pixels, we should use tail
recursion rather than head recursion in onFilterBounds().
This actually only makes a difference for drop-shadow, where
the computation is non-commutative. Blur and morphology commute, but I
moved them to tail recursion anyway for clarity (so all onFilterBounds
use tail recursion).
BUG=skia:
R=bsalomon@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/481273005
In SkBBoxHierarchyRecord:
Since the bounds we pass to saveLayer are in the pre-filtering
coordinate space, they aren't correct for determining the actual
device pixels touched by the saveLayer in this case.
The easiest fix for now is to pass the clip bounds, since the final
draw done in restore() will never draw outside the clip.
In SkRecordDraw:
We do adjust the bounds passed to saveLayer, so we just need to make
sure that when we're using a paint that may affect transparent black,
we ignore the calculated bounds of draw ops and use the clip intersected
with those adjusted bounds.
See originally crrev.com/497773002
BUG=skia:
R=reed@google.com, senorblanco@chromium.org, junov@chromium.org, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/496963003
the rebaseline tool adds whitespace at the end of lines in the json file.
While harmless, git flags this as something worth fixing. Fixing it causes
the rebaseline tool to generate a new difference with the whitespace.
Checking the whitespace back in to avoid future back-and-forth.
TBR=
NOTRY=true
NOTREECHECKS=true
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/494363002
The overarching goal here is for our "gm" and "render_pictures" tools to handle
image expectations/actuals in the same way, sharing the same code, so their
results can be processed through a single pipeline.
By adding an Expectation class within tools/image_expectations.h, similar to
the Expectations class in gm/gm_expectations.h, we get one step closer to
that goal.
R=stephana@google.com
TBR=stephana
Author: epoger@google.com
Review URL: https://codereview.chromium.org/493363002
This will expand the cheat to just big enough to pass an assertion coming
from our GDI bot. Currently failing:
-6.000000 -1.500000 6.000000 1.500000 vs. -1.000000 -2.000000 3.000000 1.000000
Will become (-8 -2 8 2) vs. (-1 -2 3 1).
BUG=skia:
R=mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/496153002
Chrome's using a bounding box, so it's a good idea for our
bots to do so too.
When set, we'll create an SkTileGrid to match the
parameters of --clip, and so should always hit its fast
path.
This will impose a small overhead (querying the BBH) on all
SKPs, but make large SKPs render more quickly. E.g. on
GPU desk_pokemonwiki should show about a 30% improvement,
tabl_mozilla about 40%, and one very long page from my
personal suite, askmefast.com, gets 5x faster.
(The performance changes are not the point of the CL, but
something we should be aware of.)
BUG=
R=bsalomon@google.com, mtklein@google.com, robertphillips@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/497493003
