Fix filter primitive bounds computations.

Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the (unmodified) clip bounds to the root node
of the DAG in the first recursive call to onFilterImage() 
as the Context's fClipBounds.

2) Reverse-map the clip: when recursing up the DAG in 
filterInput[GPU](), apply filter-specific expansion to the 
clip by calling calling onFilterNodeBounds(... kReverse).
This allows upstream nodes to have a clip that respects the
current node's requirements. This is done via helper 
function mapContext().

3) Forward-map the source bitmap: just prior to applying 
the crop rect in applyCropRect(), we determine the filter's 
preferred bounds by mapping the source bitmap bounds 
forwards via onFilterNodeBounds(..., kForward).

NOTE: GMs affected by this change:
fast_slow_blurimagefilter: fast and slow paths now produce the same result
spritebitmap: drawSprite() and drawBitmap() paths now produce the same result
filterfastbounds: fast bounds are optimized; all drop-shadow results now appear
apply-filter: snug and not-snug cases give same results
dropshadowimagefilter: drawSprite() results now show shadows
draw-with-filter: no artifacts on erode edges; blur edges no longer clipped
displacement, imagefiltersbase, imagefiltersclipped, imagefilterscropexpand, imagefiltersscaled, matriximagefilter, 
resizeimagefilter, localmatriximagefilter, testimagefilters: fixed incorrect clipping
imagefilterstransformed, morphology: no artifacts on erode edges

BUG=skia:1062, skia:3194, skia:3939, skia:4337, skia:4526
Committed: https://skia.googlesource.com/skia/+/db64af3b178a19ecb47d2b9a373113687d8921fd

[Stephen White, 2015-12-01 22:47:47]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination bounds,
performed in SkImageFilter::applyCropRect().  This allows us to stop
using a union of src and dst bounds in pixel-moving image filters
(matrix, offset, tile).

Note: patch is rooted on https://codereview.chromium.org/1304883004/,
and requires that to land first.

BUG=skia:1062,skia:3194,skia:3936,skia:3939
NOTREECHECKS=true
NOTRY=true
NOPRESUBMIT=true
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination bounds,
performed in SkImageFilter::applyCropRect().  This allows us to stop
using a union of src and dst bounds in pixel-moving image filters
(matrix, offset, tile).

BUG=skia:1062,skia:3194,skia:3936,skia:3939
==========

[Stephen White, 2015-12-01 22:55:37]

The CQ bit was checked by senorblanco@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-12-01 22:55:50]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308703007/400001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308703007/400001

[commit-bot: I haz the power, 2015-12-01 22:59:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-12-01 22:59:24]

Dry run: Try jobs failed on following builders:
  Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-Shared-Trybot on client.skia
(JOB_FAILED,
http://build.chromium.org/p/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2...)

[Stephen White, 2015-12-07 17:43:03]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination bounds,
performed in SkImageFilter::applyCropRect().  This allows us to stop
using a union of src and dst bounds in pixel-moving image filters
(matrix, offset, tile).

BUG=skia:1062,skia:3194,skia:3936,skia:3939
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination bounds,
performed in SkImageFilter::applyCropRect().  This allows us to stop
using a union of src and dst bounds in pixel-moving image filters
(matrix, offset, tile).

BUG=skia:1062,skia:3194,skia:3939
==========

[Stephen White, 2015-12-07 18:02:42]

The CQ bit was checked by senorblanco@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-12-07 18:02:47]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308703007/460001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308703007/460001

[commit-bot: I haz the power, 2015-12-07 18:18:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-12-07 18:18:26]

Dry run: This issue passed the CQ dry run.

[Stephen White, 2015-12-07 18:32:06]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination bounds,
performed in SkImageFilter::applyCropRect().  This allows us to stop
using a union of src and dst bounds in pixel-moving image filters
(matrix, offset, tile).

BUG=skia:1062,skia:3194,skia:3939
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination bounds,
performed in SkImageFilter::applyCropRect().  This allows us to stop
using a union of src and dst bounds in pixel-moving image filters
(matrix, offset, tile).

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

[Stephen White, 2015-12-07 18:32:07]

senorblanco@chromium.org changed reviewers:
+ reed@google.com

[Stephen White, 2015-12-07 18:41:36]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination bounds,
performed in SkImageFilter::applyCropRect().  This allows us to stop
using a union of src and dst bounds in pixel-moving image filters
(matrix, offset, tile).

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination bounds. Previously,
we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we pass the original (non-expanded) clip
bounds into the first recursive call to onFilterImage().
Then, we expand the clip bounds backwards by calling onFilterNodeBounds(...
kReverse) as we recurse on each
input in filterInput(), and then expand the filtered source
bitmap bounds forwards via onFilterNodeBounds(..., kForward).

We do the filter-specific expansion by calling
onFilterNodeBounds() to map the input bitmap forwards, and
determine the filter's preferred
destination size, just prior to applying the crop rect in
SkImageFilter::applyCropRect().

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

[Stephen White, 2015-12-07 18:41:52]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination bounds. Previously,
we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we pass the original (non-expanded) clip
bounds into the first recursive call to onFilterImage().
Then, we expand the clip bounds backwards by calling onFilterNodeBounds(...
kReverse) as we recurse on each
input in filterInput(), and then expand the filtered source
bitmap bounds forwards via onFilterNodeBounds(..., kForward).

We do the filter-specific expansion by calling
onFilterNodeBounds() to map the input bitmap forwards, and
determine the filter's preferred
destination size, just prior to applying the crop rect in
SkImageFilter::applyCropRect().

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we pass the original (non-expanded) clip
bounds into the first recursive call to onFilterImage().
Then, we expand the clip bounds backwards by calling onFilterNodeBounds(...
kReverse) as we recurse on each
input in filterInput(), and then expand the filtered source
bitmap bounds forwards via onFilterNodeBounds(..., kForward).

We do the filter-specific expansion by calling
onFilterNodeBounds() to map the input bitmap forwards, and
determine the filter's preferred
destination size, just prior to applying the crop rect in
SkImageFilter::applyCropRect().

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

[Stephen White, 2015-12-07 18:42:18]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we pass the original (non-expanded) clip
bounds into the first recursive call to onFilterImage().
Then, we expand the clip bounds backwards by calling onFilterNodeBounds(...
kReverse) as we recurse on each
input in filterInput(), and then expand the filtered source
bitmap bounds forwards via onFilterNodeBounds(..., kForward).

We do the filter-specific expansion by calling
onFilterNodeBounds() to map the input bitmap forwards, and
determine the filter's preferred
destination size, just prior to applying the crop rect in
SkImageFilter::applyCropRect().

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we pass the original (non-expanded) clip
bounds into the first recursive call to onFilterImage().
Then, we expand the clip bounds backwards by calling 
onFilterNodeBounds(... kReverse) as we recurse on each
input in filterInput(), and then expand the filtered source
bitmap bounds forwards via onFilterNodeBounds(..., kForward).

We do the filter-specific expansion by calling
onFilterNodeBounds() to map the input bitmap forwards, and
determine the filter's preferred
destination size, just prior to applying the crop rect in
SkImageFilter::applyCropRect().

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

[Stephen White, 2015-12-07 18:42:44]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we pass the original (non-expanded) clip
bounds into the first recursive call to onFilterImage().
Then, we expand the clip bounds backwards by calling 
onFilterNodeBounds(... kReverse) as we recurse on each
input in filterInput(), and then expand the filtered source
bitmap bounds forwards via onFilterNodeBounds(..., kForward).

We do the filter-specific expansion by calling
onFilterNodeBounds() to map the input bitmap forwards, and
determine the filter's preferred
destination size, just prior to applying the crop rect in
SkImageFilter::applyCropRect().

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we pass the original (non-expanded) clip
bounds into the first recursive call to onFilterImage().
Then, we expand the clip bounds backwards by calling 
onFilterNodeBounds(... kReverse) as we recurse on each
input in filterInput(), and then expand the filtered source
bitmap bounds forwards via onFilterNodeBounds(..., kForward).

We do the filter-specific expansion by calling
onFilterNodeBounds() to map the input bitmap forwards, and
determine the filter's preferred destination size, just
prior to applying the crop rect in SkImageFilter::applyCropRect().

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

[Stephen White, 2015-12-07 18:44:16]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we pass the original (non-expanded) clip
bounds into the first recursive call to onFilterImage().
Then, we expand the clip bounds backwards by calling 
onFilterNodeBounds(... kReverse) as we recurse on each
input in filterInput(), and then expand the filtered source
bitmap bounds forwards via onFilterNodeBounds(..., kForward).

We do the filter-specific expansion by calling
onFilterNodeBounds() to map the input bitmap forwards, and
determine the filter's preferred destination size, just
prior to applying the crop rect in SkImageFilter::applyCropRect().

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we pass the original (non-expanded) clip
bounds into the first recursive call to onFilterImage().
Then, we do the filter-specific clip expansion by calling calling 
onFilterNodeBounds(... kReverse) with the clip as we 
recurse on each input in filterInput(). Then, we expand the 
filtered source bitmap bounds forwards via 
onFilterNodeBounds(..., kForward) to map the input bitmap 
forwards, and determine the filter's preferred destination 
size, just prior to applying the crop rect in 
SkImageFilter::applyCropRect().

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

[Stephen White, 2015-12-07 18:49:34]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we pass the original (non-expanded) clip
bounds into the first recursive call to onFilterImage().
Then, we do the filter-specific clip expansion by calling calling 
onFilterNodeBounds(... kReverse) with the clip as we 
recurse on each input in filterInput(). Then, we expand the 
filtered source bitmap bounds forwards via 
onFilterNodeBounds(..., kForward) to map the input bitmap 
forwards, and determine the filter's preferred destination 
size, just prior to applying the crop rect in 
SkImageFilter::applyCropRect().

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the unmodified clip bounds into the 
first recursive call to onFilterImage() as the Context's
fClipBounds.
2) Reverse-map the clip: when recursing up the DAG in filterInput[GPU](), apply
filter-specific expansion to the clip by calling calling 
onFilterNodeBounds(... kReverse). This allows upstream nodes to have a clip that
respects the current node's 
requirements. This is done via helper function 
mapContext().
3) Forward-map the source bitmap: just prior to applying the crop rect in
applyCropRect(), 
we determine the filter's preferred bounds by mapping
the source bitmap bounds fowards via
onFilterNodeBounds(..., kForward).

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

[Stephen White, 2015-12-07 18:50:01]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the unmodified clip bounds into the 
first recursive call to onFilterImage() as the Context's
fClipBounds.
2) Reverse-map the clip: when recursing up the DAG in filterInput[GPU](), apply
filter-specific expansion to the clip by calling calling 
onFilterNodeBounds(... kReverse). This allows upstream nodes to have a clip that
respects the current node's 
requirements. This is done via helper function 
mapContext().
3) Forward-map the source bitmap: just prior to applying the crop rect in
applyCropRect(), 
we determine the filter's preferred bounds by mapping
the source bitmap bounds fowards via
onFilterNodeBounds(..., kForward).

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the (unmodified) clip bounds into the 
first recursive call to onFilterImage() as the Context's
fClipBounds.
2) Reverse-map the clip: when recursing up the DAG in filterInput[GPU](), apply
filter-specific expansion to the clip by calling calling 
onFilterNodeBounds(... kReverse). This allows upstream nodes to have a clip that
respects the current node's 
requirements. This is done via helper function 
mapContext().
3) Forward-map the source bitmap: just prior to applying the crop rect in
applyCropRect(), 
we determine the filter's preferred bounds by mapping
the source bitmap bounds fowards via
onFilterNodeBounds(..., kForward).

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

[Stephen White, 2015-12-07 18:50:23]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the (unmodified) clip bounds into the 
first recursive call to onFilterImage() as the Context's
fClipBounds.
2) Reverse-map the clip: when recursing up the DAG in filterInput[GPU](), apply
filter-specific expansion to the clip by calling calling 
onFilterNodeBounds(... kReverse). This allows upstream nodes to have a clip that
respects the current node's 
requirements. This is done via helper function 
mapContext().
3) Forward-map the source bitmap: just prior to applying the crop rect in
applyCropRect(), 
we determine the filter's preferred bounds by mapping
the source bitmap bounds fowards via
onFilterNodeBounds(..., kForward).

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the (unmodified) clip bounds to the root node
of the DAG in the first recursive call to onFilterImage() 
as the Context's fClipBounds.
2) Reverse-map the clip: when recursing up the DAG in filterInput[GPU](), apply
filter-specific expansion to the clip by calling calling 
onFilterNodeBounds(... kReverse). This allows upstream nodes to have a clip that
respects the current node's 
requirements. This is done via helper function 
mapContext().
3) Forward-map the source bitmap: just prior to applying the crop rect in
applyCropRect(), 
we determine the filter's preferred bounds by mapping
the source bitmap bounds fowards via
onFilterNodeBounds(..., kForward).

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

[reed1, 2015-12-07 19:56:08]

just applied it locally, it it does seem to fix a lot of artifacts. Awesome!

[Stephen White, 2015-12-07 20:15:30]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the (unmodified) clip bounds to the root node
of the DAG in the first recursive call to onFilterImage() 
as the Context's fClipBounds.
2) Reverse-map the clip: when recursing up the DAG in filterInput[GPU](), apply
filter-specific expansion to the clip by calling calling 
onFilterNodeBounds(... kReverse). This allows upstream nodes to have a clip that
respects the current node's 
requirements. This is done via helper function 
mapContext().
3) Forward-map the source bitmap: just prior to applying the crop rect in
applyCropRect(), 
we determine the filter's preferred bounds by mapping
the source bitmap bounds fowards via
onFilterNodeBounds(..., kForward).

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the (unmodified) clip bounds to the root node
of the DAG in the first recursive call to onFilterImage() 
as the Context's fClipBounds.

2) Reverse-map the clip: when recursing up the DAG in 
filterInput[GPU](), apply filter-specific expansion to the 
clip by calling calling onFilterNodeBounds(... kReverse).
This allows upstream nodes to have a clip that respects the
current node's requirements. This is done via helper 
function mapContext().

3) Forward-map the source bitmap: just prior to applying 
the crop rect in applyCropRect(), we determine the filter's 
preferred bounds by mapping the source bitmap bounds 
forwards viaonFilterNodeBounds(..., kForward).

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

[reed1, 2015-12-07 20:24:10]

reed@google.com changed reviewers:
+ mtklein@google.com

[reed1, 2015-12-07 20:24:11]

https://codereview.chromium.org/1308703007/diff/480001/src/core/SkRecordDraw.cpp
File src/core/SkRecordDraw.cpp (right):

https://codereview.chromium.org/1308703007/diff/480001/src/core/SkRecordDraw....
src/core/SkRecordDraw.cpp:572: inverse.mapRect(rect);
Is this change a fix in its own right, or is it connected to the change for
imagefilters?

- I assume AdjustForPaint wants its rectangle in local coordinates
- I assume the parameter passed to adjustForSaveLayerPaints is in global
coordinates

If both of these are true, then it seems like we have a bug outside of this
CL...?

[reed1, 2015-12-07 20:26:20]

https://codereview.chromium.org/1308703007/diff/480001/src/gpu/SkGpuDevice.cpp
File src/gpu/SkGpuDevice.cpp (right):

https://codereview.chromium.org/1308703007/diff/480001/src/gpu/SkGpuDevice.cp...
src/gpu/SkGpuDevice.cpp:1166: SkIRect clipBounds = draw.fClip->getBounds();
option: could use (your pref)

SkIRect clipBounds = draw.fClip->getBounds().makeOffset(-left, -top);

That lets you declare the lvalue as const if you like.

[Stephen White, 2015-12-07 20:29:40]

https://codereview.chromium.org/1308703007/diff/480001/src/core/SkRecordDraw.cpp
File src/core/SkRecordDraw.cpp (right):

https://codereview.chromium.org/1308703007/diff/480001/src/core/SkRecordDraw....
src/core/SkRecordDraw.cpp:572: inverse.mapRect(rect);
On 2015/12/07 20:24:11, reed1 wrote:
> Is this change a fix in its own right, or is it connected to the change for
> imagefilters?
> 
> - I assume AdjustForPaint wants its rectangle in local coordinates
> - I assume the parameter passed to adjustForSaveLayerPaints is in global
> coordinates
> 
> If both of these are true, then it seems like we have a bug outside of this
> CL...?

IIRC the problem/bug was being papered over by the join() calls, which
were previously making adjustForSaveLayerPaints() work regardless. 
When I removed the join() calls, tiled picture playback started
showing artifacts.

I'm going to take another look to see if this change is still necessary.

[Stephen White, 2015-12-07 20:51:15]

https://codereview.chromium.org/1308703007/diff/480001/src/core/SkRecordDraw.cpp
File src/core/SkRecordDraw.cpp (right):

https://codereview.chromium.org/1308703007/diff/480001/src/core/SkRecordDraw....
src/core/SkRecordDraw.cpp:572: inverse.mapRect(rect);
On 2015/12/07 20:29:40, Stephen White wrote:
> On 2015/12/07 20:24:11, reed1 wrote:
> > Is this change a fix in its own right, or is it connected to the change for
> > imagefilters?
> > 
> > - I assume AdjustForPaint wants its rectangle in local coordinates
> > - I assume the parameter passed to adjustForSaveLayerPaints is in global
> > coordinates
> > 
> > If both of these are true, then it seems like we have a bug outside of this
> > CL...?
> 
> IIRC the problem/bug was being papered over by the join() calls, which
> were previously making adjustForSaveLayerPaints() work regardless. 
> When I removed the join() calls, tiled picture playback started
> showing artifacts.
> 
> I'm going to take another look to see if this change is still necessary.

To follow up: this breaks layout tests css3/filters/effect-reference-tile.html
and effect-reference-subregion-hw.html over in Chrome,
both with respect to SkTileImageFilter. There's no Skia test coverage
for this case ATM; I'll try to construct some.

The problem is that filters apply the CTM that was in effect
at saveLayer() time to their filter parameters, not the current CTM.
So we need to capture that CTM, and use it when transforming rects 
backwards through the saveLayer stack.

This affects SkTileImageFilter, since its computeFastBounds()
basically ignores the rect passed to it, and always returns its 
fDstRect, since it always draws its result to that location.

That said, I'm not 100% certain that this change is correct.

[reed1, 2015-12-07 21:17:23]

Gotcha.

[Stephen White, 2015-12-07 21:34:23]

https://codereview.chromium.org/1308703007/diff/480001/src/gpu/SkGpuDevice.cpp
File src/gpu/SkGpuDevice.cpp (right):

https://codereview.chromium.org/1308703007/diff/480001/src/gpu/SkGpuDevice.cp...
src/gpu/SkGpuDevice.cpp:1166: SkIRect clipBounds = draw.fClip->getBounds();
On 2015/12/07 20:26:20, reed1 wrote:
> option: could use (your pref)
> 
> SkIRect clipBounds = draw.fClip->getBounds().makeOffset(-left, -top);
> 
> That lets you declare the lvalue as const if you like.

Good idea! Done.

[Stephen White, 2015-12-07 21:38:55]

The CQ bit was checked by senorblanco@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-12-07 21:39:06]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308703007/520001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308703007/520001

[Stephen White, 2015-12-07 21:43:09]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the (unmodified) clip bounds to the root node
of the DAG in the first recursive call to onFilterImage() 
as the Context's fClipBounds.

2) Reverse-map the clip: when recursing up the DAG in 
filterInput[GPU](), apply filter-specific expansion to the 
clip by calling calling onFilterNodeBounds(... kReverse).
This allows upstream nodes to have a clip that respects the
current node's requirements. This is done via helper 
function mapContext().

3) Forward-map the source bitmap: just prior to applying 
the crop rect in applyCropRect(), we determine the filter's 
preferred bounds by mapping the source bitmap bounds 
forwards viaonFilterNodeBounds(..., kForward).

BUG=skia:1062,skia:3194,skia:3939,skia:4337
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the (unmodified) clip bounds to the root node
of the DAG in the first recursive call to onFilterImage() 
as the Context's fClipBounds.

2) Reverse-map the clip: when recursing up the DAG in 
filterInput[GPU](), apply filter-specific expansion to the 
clip by calling calling onFilterNodeBounds(... kReverse).
This allows upstream nodes to have a clip that respects the
current node's requirements. This is done via helper 
function mapContext().

3) Forward-map the source bitmap: just prior to applying 
the crop rect in applyCropRect(), we determine the filter's 
preferred bounds by mapping the source bitmap bounds 
forwards viaonFilterNodeBounds(..., kForward).

BUG=skia:1062,skia:3194,skia:3939,skia:4337,skia:4526
==========

[commit-bot: I haz the power, 2015-12-07 21:53:21]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-12-07 21:53:21]

Dry run: This issue passed the CQ dry run.

[Stephen White, 2015-12-09 15:02:24]

The CQ bit was checked by senorblanco@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-12-09 15:02:42]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308703007/540001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308703007/540001

[Stephen White, 2015-12-09 15:41:37]

The CQ bit was checked by senorblanco@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-12-09 15:41:48]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308703007/580001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308703007/580001

[Stephen White, 2015-12-09 15:42:08]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the (unmodified) clip bounds to the root node
of the DAG in the first recursive call to onFilterImage() 
as the Context's fClipBounds.

2) Reverse-map the clip: when recursing up the DAG in 
filterInput[GPU](), apply filter-specific expansion to the 
clip by calling calling onFilterNodeBounds(... kReverse).
This allows upstream nodes to have a clip that respects the
current node's requirements. This is done via helper 
function mapContext().

3) Forward-map the source bitmap: just prior to applying 
the crop rect in applyCropRect(), we determine the filter's 
preferred bounds by mapping the source bitmap bounds 
forwards viaonFilterNodeBounds(..., kForward).

BUG=skia:1062,skia:3194,skia:3939,skia:4337,skia:4526
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the (unmodified) clip bounds to the root node
of the DAG in the first recursive call to onFilterImage() 
as the Context's fClipBounds.

2) Reverse-map the clip: when recursing up the DAG in 
filterInput[GPU](), apply filter-specific expansion to the 
clip by calling calling onFilterNodeBounds(... kReverse).
This allows upstream nodes to have a clip that respects the
current node's requirements. This is done via helper 
function mapContext().

3) Forward-map the source bitmap: just prior to applying 
the crop rect in applyCropRect(), we determine the filter's 
preferred bounds by mapping the source bitmap bounds 
forwards via onFilterNodeBounds(..., kForward).

BUG=skia:1062,skia:3194,skia:3939,skia:4337,skia:4526
==========

[commit-bot: I haz the power, 2015-12-09 15:55:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-12-09 15:55:19]

Dry run: This issue passed the CQ dry run.

[Stephen White, 2015-12-09 16:01:18]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the (unmodified) clip bounds to the root node
of the DAG in the first recursive call to onFilterImage() 
as the Context's fClipBounds.

2) Reverse-map the clip: when recursing up the DAG in 
filterInput[GPU](), apply filter-specific expansion to the 
clip by calling calling onFilterNodeBounds(... kReverse).
This allows upstream nodes to have a clip that respects the
current node's requirements. This is done via helper 
function mapContext().

3) Forward-map the source bitmap: just prior to applying 
the crop rect in applyCropRect(), we determine the filter's 
preferred bounds by mapping the source bitmap bounds 
forwards via onFilterNodeBounds(..., kForward).

BUG=skia:1062,skia:3194,skia:3939,skia:4337,skia:4526
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the (unmodified) clip bounds to the root node
of the DAG in the first recursive call to onFilterImage() 
as the Context's fClipBounds.

2) Reverse-map the clip: when recursing up the DAG in 
filterInput[GPU](), apply filter-specific expansion to the 
clip by calling calling onFilterNodeBounds(... kReverse).
This allows upstream nodes to have a clip that respects the
current node's requirements. This is done via helper 
function mapContext().

3) Forward-map the source bitmap: just prior to applying 
the crop rect in applyCropRect(), we determine the filter's 
preferred bounds by mapping the source bitmap bounds 
forwards via onFilterNodeBounds(..., kForward).

NOTE: GMs affected by this change:
fast_slow_blurimagefilter: fast and slow paths now produce the same result
spritebitmap: drawSprite() and drawBitmap() paths now produce the same result
imagefilterstransformed: morphology border treatment is correct
filterfastbounds: fast bounds are optimized; all drop-shadow results now appear
apply-filter: snug and not-snug cases give same results (no artifacts)
dropshadowimagefilter: drawSprite() results now show shadows
draw-with-filter: no artifacts on erode edges; blur edges no longer clipped
displacement, imagefiltersbase, imagefiltersclipped, imagefilterscropexpand,
imagefiltersscaled, matriximagefilter, resizeimagefilter,
localmatriximagefilter, testimagefilters: fixed incorrect clipping
morphology: no artifacts on erode edges
BUG=skia:1062,skia:3194,skia:3939,skia:4337,skia:4526
==========

[Stephen White, 2015-12-09 16:02:40]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the (unmodified) clip bounds to the root node
of the DAG in the first recursive call to onFilterImage() 
as the Context's fClipBounds.

2) Reverse-map the clip: when recursing up the DAG in 
filterInput[GPU](), apply filter-specific expansion to the 
clip by calling calling onFilterNodeBounds(... kReverse).
This allows upstream nodes to have a clip that respects the
current node's requirements. This is done via helper 
function mapContext().

3) Forward-map the source bitmap: just prior to applying 
the crop rect in applyCropRect(), we determine the filter's 
preferred bounds by mapping the source bitmap bounds 
forwards via onFilterNodeBounds(..., kForward).

NOTE: GMs affected by this change:
fast_slow_blurimagefilter: fast and slow paths now produce the same result
spritebitmap: drawSprite() and drawBitmap() paths now produce the same result
imagefilterstransformed: morphology border treatment is correct
filterfastbounds: fast bounds are optimized; all drop-shadow results now appear
apply-filter: snug and not-snug cases give same results (no artifacts)
dropshadowimagefilter: drawSprite() results now show shadows
draw-with-filter: no artifacts on erode edges; blur edges no longer clipped
displacement, imagefiltersbase, imagefiltersclipped, imagefilterscropexpand,
imagefiltersscaled, matriximagefilter, resizeimagefilter,
localmatriximagefilter, testimagefilters: fixed incorrect clipping
morphology: no artifacts on erode edges
BUG=skia:1062,skia:3194,skia:3939,skia:4337,skia:4526
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the (unmodified) clip bounds to the root node
of the DAG in the first recursive call to onFilterImage() 
as the Context's fClipBounds.

2) Reverse-map the clip: when recursing up the DAG in 
filterInput[GPU](), apply filter-specific expansion to the 
clip by calling calling onFilterNodeBounds(... kReverse).
This allows upstream nodes to have a clip that respects the
current node's requirements. This is done via helper 
function mapContext().

3) Forward-map the source bitmap: just prior to applying 
the crop rect in applyCropRect(), we determine the filter's 
preferred bounds by mapping the source bitmap bounds 
forwards via onFilterNodeBounds(..., kForward).

NOTE: GMs affected by this change:
fast_slow_blurimagefilter: fast and slow paths now produce the same result
spritebitmap: drawSprite() and drawBitmap() paths now produce the same result
filterfastbounds: fast bounds are optimized; all drop-shadow results now appear
apply-filter: snug and not-snug cases give same results
dropshadowimagefilter: drawSprite() results now show shadows
draw-with-filter: no artifacts on erode edges; blur edges no longer clipped
displacement, imagefiltersbase, imagefiltersclipped, imagefilterscropexpand,
imagefiltersscaled, matriximagefilter, 
resizeimagefilter, localmatriximagefilter, testimagefilters: fixed incorrect
clipping
imagefilterstransformed, morphology: no artifacts on erode edges

BUG=skia:1062,skia:3194,skia:3939,skia:4337,skia:4526
==========

[Stephen White, 2015-12-09 16:03:38]

reed@, mtklein@: PTAL. Thanks!

[reed1, 2015-12-09 16:11:41]

landing this will make me very happy. congrats on a big fix.

lgtm

https://codereview.chromium.org/1308703007/diff/580001/include/core/SkImageFi...
File include/core/SkImageFilter.h (right):

https://codereview.chromium.org/1308703007/diff/580001/include/core/SkImageFi...
include/core/SkImageFilter.h:354: // Performs a forwards or reverse mapping of
the given rect to accommodate
nit: can we use /** comment style here? Partly for consistency, and partly for
doxygen.

https://codereview.chromium.org/1308703007/diff/580001/include/effects/SkBlur...
File include/effects/SkBlurImageFilter.h (right):

https://codereview.chromium.org/1308703007/diff/580001/include/effects/SkBlur...
include/effects/SkBlurImageFilter.h:31: SkIRect* dst, MapDirection direction)
const override;
trivial nit: don't need 'direction', since the type name says it all.

[Stephen White, 2015-12-09 16:52:41]

The CQ bit was checked by senorblanco@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-12-09 16:52:51]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308703007/600001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308703007/600001

[mtklein, 2015-12-09 16:59:41]

I'm on board!

https://codereview.chromium.org/1308703007/diff/600001/src/core/SkRecordDraw.cpp
File src/core/SkRecordDraw.cpp (right):

https://codereview.chromium.org/1308703007/diff/600001/src/core/SkRecordDraw....
src/core/SkRecordDraw.cpp:576: fSaveStack[i].ctm.mapRect(rect);
Is it important that we do rect = (M (M^-1 rect)) here?

I'd just have expected to stash away the original rect and restore it by a
simple copy instead of re-mapping.

[mtklein, 2015-12-09 17:00:53]

https://codereview.chromium.org/1308703007/diff/600001/src/core/SkRecordDraw.cpp
File src/core/SkRecordDraw.cpp (right):

https://codereview.chromium.org/1308703007/diff/600001/src/core/SkRecordDraw....
src/core/SkRecordDraw.cpp:576: fSaveStack[i].ctm.mapRect(rect);
On 2015/12/09 at 16:59:41, mtklein wrote:
> Is it important that we do rect = (M (M^-1 rect)) here?
> 
> I'd just have expected to stash away the original rect and restore it by a
simple copy instead of re-mapping.

(Or put (M^-1 rect) into another SkRect instead of doing it in place in rect?)

[Stephen White, 2015-12-09 17:02:57]

https://codereview.chromium.org/1308703007/diff/580001/include/core/SkImageFi...
File include/core/SkImageFilter.h (right):

https://codereview.chromium.org/1308703007/diff/580001/include/core/SkImageFi...
include/core/SkImageFilter.h:354: // Performs a forwards or reverse mapping of
the given rect to accommodate
On 2015/12/09 16:11:41, reed1 wrote:
> nit: can we use /** comment style here? Partly for consistency, and partly for
> doxygen.

Done.

https://codereview.chromium.org/1308703007/diff/580001/include/effects/SkBlur...
File include/effects/SkBlurImageFilter.h (right):

https://codereview.chromium.org/1308703007/diff/580001/include/effects/SkBlur...
include/effects/SkBlurImageFilter.h:31: SkIRect* dst, MapDirection direction)
const override;
On 2015/12/09 16:11:41, reed1 wrote:
> trivial nit: don't need 'direction', since the type name says it all.

Done (here and elsewhere).

https://codereview.chromium.org/1308703007/diff/600001/src/core/SkRecordDraw.cpp
File src/core/SkRecordDraw.cpp (right):

https://codereview.chromium.org/1308703007/diff/600001/src/core/SkRecordDraw....
src/core/SkRecordDraw.cpp:576: fSaveStack[i].ctm.mapRect(rect);
On 2015/12/09 17:00:53, mtklein wrote:
> On 2015/12/09 at 16:59:41, mtklein wrote:
> > Is it important that we do rect = (M (M^-1 rect)) here?
> > 
> > I'd just have expected to stash away the original rect and restore it by a
> simple copy instead of re-mapping.
> 
> (Or put (M^-1 rect) into another SkRect instead of doing it in place in rect?)

The problem is that we don't know the rect at saveLayer time: we're trying to
map some primitive that we're drawing [1..N] saveLayers 
deep.

That said, at a minimum I should probably stash the matrix inverse on 
the save stack as well, to avoid inverting it each time.

[commit-bot: I haz the power, 2015-12-09 17:03:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-12-09 17:03:48]

Dry run: This issue passed the CQ dry run.

[mtklein, 2015-12-09 17:06:04]

https://codereview.chromium.org/1308703007/diff/600001/src/core/SkRecordDraw.cpp
File src/core/SkRecordDraw.cpp (right):

https://codereview.chromium.org/1308703007/diff/600001/src/core/SkRecordDraw....
src/core/SkRecordDraw.cpp:576: fSaveStack[i].ctm.mapRect(rect);
So, (*rect at line 577) != (*rect at line 571)?

[Stephen White, 2015-12-09 17:10:52]

https://codereview.chromium.org/1308703007/diff/600001/src/core/SkRecordDraw.cpp
File src/core/SkRecordDraw.cpp (right):

https://codereview.chromium.org/1308703007/diff/600001/src/core/SkRecordDraw....
src/core/SkRecordDraw.cpp:576: fSaveStack[i].ctm.mapRect(rect);
On 2015/12/09 17:06:04, mtklein wrote:
> So, (*rect at line 577) != (*rect at line 571)?

Yeah. It may have been munged by AdjustForPaint(). I'm essentially 
attempting to ensure that that munging is done relative to the 
layer's origin, which unfortunately we don't have access to here.

[mtklein, 2015-12-09 17:15:25]

https://codereview.chromium.org/1308703007/diff/600001/src/core/SkRecordDraw.cpp
File src/core/SkRecordDraw.cpp (right):

https://codereview.chromium.org/1308703007/diff/600001/src/core/SkRecordDraw....
src/core/SkRecordDraw.cpp:576: fSaveStack[i].ctm.mapRect(rect);
On 2015/12/09 at 17:10:52, Stephen White wrote:
> On 2015/12/09 17:06:04, mtklein wrote:
> > So, (*rect at line 577) != (*rect at line 571)?
> 
> Yeah. It may have been munged by AdjustForPaint(). I'm essentially 
> attempting to ensure that that munging is done relative to the 
> layer's origin, which unfortunately we don't have access to here.

Oh, of course.  That's the whole point of this method.  Duh.

I'm ok to wait until we see the inverts matter on a profile before we stash the
inverse.

[reed1, 2015-12-09 17:17:40]

On 2015/12/09 17:15:25, mtklein wrote:
>
https://codereview.chromium.org/1308703007/diff/600001/src/core/SkRecordDraw.cpp
> File src/core/SkRecordDraw.cpp (right):
> 
>
https://codereview.chromium.org/1308703007/diff/600001/src/core/SkRecordDraw....
> src/core/SkRecordDraw.cpp:576: fSaveStack[i].ctm.mapRect(rect);
> On 2015/12/09 at 17:10:52, Stephen White wrote:
> > On 2015/12/09 17:06:04, mtklein wrote:
> > > So, (*rect at line 577) != (*rect at line 571)?
> > 
> > Yeah. It may have been munged by AdjustForPaint(). I'm essentially 
> > attempting to ensure that that munging is done relative to the 
> > layer's origin, which unfortunately we don't have access to here.
> 
> Oh, of course.  That's the whole point of this method.  Duh.
> 
> I'm ok to wait until we see the inverts matter on a profile before we stash
the
> inverse.

Agreed. The common matrices from chrome/android will be scale/translate only,
and we should detect that invert them pretty quickly.

[mtklein, 2015-12-09 17:18:59]

On 2015/12/09 at 17:15:25, mtklein wrote:
>
https://codereview.chromium.org/1308703007/diff/600001/src/core/SkRecordDraw.cpp
> File src/core/SkRecordDraw.cpp (right):
> 
>
https://codereview.chromium.org/1308703007/diff/600001/src/core/SkRecordDraw....
> src/core/SkRecordDraw.cpp:576: fSaveStack[i].ctm.mapRect(rect);
> On 2015/12/09 at 17:10:52, Stephen White wrote:
> > On 2015/12/09 17:06:04, mtklein wrote:
> > > So, (*rect at line 577) != (*rect at line 571)?
> > 
> > Yeah. It may have been munged by AdjustForPaint(). I'm essentially 
> > attempting to ensure that that munging is done relative to the 
> > layer's origin, which unfortunately we don't have access to here.
> 
> Oh, of course.  That's the whole point of this method.  Duh.
> 
> I'm ok to wait until we see the inverts matter on a profile before we stash
the inverse.

(lgtm)

[Stephen White, 2015-12-09 18:10:47]

The CQ bit was checked by senorblanco@chromium.org

[Stephen White, 2015-12-09 18:10:48]

The patchset sent to the CQ was uploaded after l-g-t-m from reed@google.com
Link to the patchset: https://codereview.chromium.org/1308703007/#ps600001
(title: "Fix comment style; remove useless param names")

[commit-bot: I haz the power, 2015-12-09 18:11:02]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308703007/600001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308703007/600001

[commit-bot: I haz the power, 2015-12-09 18:11:45]

Description was changed from

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the (unmodified) clip bounds to the root node
of the DAG in the first recursive call to onFilterImage() 
as the Context's fClipBounds.

2) Reverse-map the clip: when recursing up the DAG in 
filterInput[GPU](), apply filter-specific expansion to the 
clip by calling calling onFilterNodeBounds(... kReverse).
This allows upstream nodes to have a clip that respects the
current node's requirements. This is done via helper 
function mapContext().

3) Forward-map the source bitmap: just prior to applying 
the crop rect in applyCropRect(), we determine the filter's 
preferred bounds by mapping the source bitmap bounds 
forwards via onFilterNodeBounds(..., kForward).

NOTE: GMs affected by this change:
fast_slow_blurimagefilter: fast and slow paths now produce the same result
spritebitmap: drawSprite() and drawBitmap() paths now produce the same result
filterfastbounds: fast bounds are optimized; all drop-shadow results now appear
apply-filter: snug and not-snug cases give same results
dropshadowimagefilter: drawSprite() results now show shadows
draw-with-filter: no artifacts on erode edges; blur edges no longer clipped
displacement, imagefiltersbase, imagefiltersclipped, imagefilterscropexpand,
imagefiltersscaled, matriximagefilter, 
resizeimagefilter, localmatriximagefilter, testimagefilters: fixed incorrect
clipping
imagefilterstransformed, morphology: no artifacts on erode edges

BUG=skia:1062,skia:3194,skia:3939,skia:4337,skia:4526
==========

to

==========
Fix filter primitive bounds computations.

Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all 
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:

1) Pass the (unmodified) clip bounds to the root node
of the DAG in the first recursive call to onFilterImage() 
as the Context's fClipBounds.

2) Reverse-map the clip: when recursing up the DAG in 
filterInput[GPU](), apply filter-specific expansion to the 
clip by calling calling onFilterNodeBounds(... kReverse).
This allows upstream nodes to have a clip that respects the
current node's requirements. This is done via helper 
function mapContext().

3) Forward-map the source bitmap: just prior to applying 
the crop rect in applyCropRect(), we determine the filter's 
preferred bounds by mapping the source bitmap bounds 
forwards via onFilterNodeBounds(..., kForward).

NOTE: GMs affected by this change:
fast_slow_blurimagefilter: fast and slow paths now produce the same result
spritebitmap: drawSprite() and drawBitmap() paths now produce the same result
filterfastbounds: fast bounds are optimized; all drop-shadow results now appear
apply-filter: snug and not-snug cases give same results
dropshadowimagefilter: drawSprite() results now show shadows
draw-with-filter: no artifacts on erode edges; blur edges no longer clipped
displacement, imagefiltersbase, imagefiltersclipped, imagefilterscropexpand,
imagefiltersscaled, matriximagefilter, 
resizeimagefilter, localmatriximagefilter, testimagefilters: fixed incorrect
clipping
imagefilterstransformed, morphology: no artifacts on erode edges

BUG=skia:1062,skia:3194,skia:3939,skia:4337,skia:4526

Committed:
https://skia.googlesource.com/skia/+/db64af3b178a19ecb47d2b9a373113687d8921fd
==========

[commit-bot: I haz the power, 2015-12-09 18:11:46]

Committed patchset #31 (id:600001) as
https://skia.googlesource.com/skia/+/db64af3b178a19ecb47d2b9a373113687d8921fd