Accelerated filters should filter unpadded primitives.

Accelerated filters should filter unpadded primitives.

Until recently, the Skia image filter infrastructure could
only produce a result image of the same size as its input
image.

For that reason, currently Blink applies filter outsets to
a layer before it passes the layer to cc. So cc sees a
layer padded with transparent black out to the filter
outsets, but has no idea how big the original layer was.
It then passes that to Skia, which produces an image of
the same size.

I've recently fixed Skia to be able to correctly draw from
the original (unpadded) texture size to the correct, padded
texture size. But to take advantage of that, we need Blink
to stop padding the texture (see PaintLayer).

This may result in a destination buffer which is of a
different size than the source, so we modify cc's drawing
to draw the destination rect.

Also, since we're giving the original (unmodified) source
rect to Skia, we no longer need to offset the crop rects
in Blink by the delta between the src and dest rects.
(Note: we can thus remove the crop offset stuff entirely
from Blink, which I'll do in a followup patch.)

Finally, note that the workaround for the
partially-occupied textures implemented (implemented in
https://codereview.chromium.org/909353003) was no
longer working when drawing to exact-size textures, due
to a bug in SkAlphaThresholdFilter. This is fixed in Skia
here:  https://codereview.chromium.org/1609573002/. That
will be required to roll into Chrome before this patch can
be landed.

BUG=568196
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/38858c57782f2a32cf4f93fcfcc35c340e665be4
Cr-Commit-Position: refs/heads/master@{#370523}

[Stephen White, 2015-12-10 15:24:34]

Description was changed from

==========
Accelerated filters should filter unpadded primitives.

Skia now has the ability to allocate optimal intermediate buffers
padded by filter-dependent padding. Here we tell Blink not to pad out
for filter outsets, and pass the original (unpadded) primitive to skia
for filtering.

NOTE: this is a WIP. While the intermediate result is correct, the
layer boundaries in cc are wrong (unpadded) with this change,
resulting in an offset image clipped by the (unpadded) primitive size.

BUG=568196
==========

to

==========
Accelerated filters should filter unpadded primitives.

Skia now has the ability to allocate optimal intermediate buffers
padded by filter-dependent padding. Here we tell Blink not to pad out
for filter outsets, and pass the original (unpadded) primitive to skia
for filtering.

NOTE: this is a WIP. While the intermediate result is correct, the
layer boundaries in cc are wrong (unpadded) with this change,
resulting in an offset image clipped by the (unpadded) primitive size.

BUG=568196
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[Stephen White, 2015-12-10 15:25:22]

Description was changed from

==========
Accelerated filters should filter unpadded primitives.

Skia now has the ability to allocate optimal intermediate buffers
padded by filter-dependent padding. Here we tell Blink not to pad out
for filter outsets, and pass the original (unpadded) primitive to skia
for filtering.

NOTE: this is a WIP. While the intermediate result is correct, the
layer boundaries in cc are wrong (unpadded) with this change,
resulting in an offset image clipped by the (unpadded) primitive size.

BUG=568196
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Accelerated filters should filter unpadded primitives.

Skia now has the ability to allocate optimal intermediate buffers
padded by filter-dependent padding. Here we tell Blink not to pad out
for filter outsets, and pass the original (unpadded) primitive to skia
for filtering.

NOTE: this is a WIP. While the intermediate result is correct, the
layer boundaries in cc are wrong (unpadded) with this change,
resulting in an offset image clipped by the (unpadded) primitive size.

BUG=568196
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[reed1, 2015-12-10 15:38:11]

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

[reed1, 2015-12-10 15:38:12]

glad we're trying to remove the client-side padding.

I'd prefer we either before, or at the sametime, replace the drawSprite with
either drawImage or applyFilter.

[Stephen White, 2015-12-10 15:44:11]

On 2015/12/10 15:38:12, reed1 wrote:
> glad we're trying to remove the client-side padding.
> 
> I'd prefer we either before, or at the sametime, replace the drawSprite with
> either drawImage or applyFilter.

Sure, no problem. The issue is that if I switch Chrome over to the new optimized
bounds
path (ie., remove SK_SUPPORT_SRC_BOUNDS_BLOAT_FOR_IMAGEFILTERS), we'll get 
double-bloating of the intermediate buffers, since both Skia and Chrome will be
bloating 
them. I think this is true whether we're using drawSprite() or drawImage().

I don't mind having double-bloating temporarily (performance issue, but not
correctness), 
but I'd prefer to have an idea of how to fix it in the same release.

[Stephen White, 2015-12-10 15:58:02]

On 2015/12/10 15:44:11, Stephen White wrote:
> On 2015/12/10 15:38:12, reed1 wrote:
> > glad we're trying to remove the client-side padding.
> > 
> > I'd prefer we either before, or at the sametime, replace the drawSprite with
> > either drawImage or applyFilter.
> 
> Sure, no problem. The issue is that if I switch Chrome over to the new
optimized
> bounds
> path (ie., remove SK_SUPPORT_SRC_BOUNDS_BLOAT_FOR_IMAGEFILTERS), we'll get 
> double-bloating of the intermediate buffers, since both Skia and Chrome will
be
> bloating 
> them. I think this is true whether we're using drawSprite() or drawImage().
> 
> I don't mind having double-bloating temporarily (performance issue, but not
> correctness), 
> but I'd prefer to have an idea of how to fix it in the same release.

Maybe that comment wasn't super-clear: if switching to drawImage()/applyFilter()
is *not* blocked on the bounds fix (removing
SK_SUPPORT_SRC_BOUNDS_BLOAT_FOR_IMAGEFILTERS), 
then we should go ahead and land your change first, and I'll try to fix the
double-bloating at the same time as switching off
SK_SUPPORT_SRC_BOUNDS_BLOAT_FOR_IMAGEFILTERS.

1) land drawImage() / applyFilter()
2a) remove SK_SUPPORT_SRC_BOUNDS_BLOAT_FOR_IMAGEFILTERS and
2b) fix double-bloating

If it is, we should try to at least have a plan in place for ameliorating the 
double-bloating. So:

1) remove SK_SUPPORT_SRC_BOUNDS_BLOAT_FOR_IMAGEFILTERS
2) land drawImage() / applyFilter()
3) fix double-bloating

Does that make sense?

[reed1, 2015-12-10 16:19:59]

I think sprite->image cl was blocked on 3 layouttests where the blurs were
different. I think those are fixed by your bloat/mapbounds fix. Thus I think
your latter 3 steps should work.

[Stephen White, 2015-12-10 22:17:34]

On 2015/12/10 16:19:59, reed1 wrote:
> I think sprite->image cl was blocked on 3 layouttests where the blurs were
> different. I think those are fixed by your bloat/mapbounds fix. Thus I think
> your latter 3 steps should work.

OK, I've landed step 1 (the SK_SUPPORT_SRC_BOUNDS_BLOAT_FOR_IMAGEFILTERS
removal) here:
https://chromium.googlesource.com/chromium/src/+/d42be13c51bbc3969f2b3b9f9e1c...

[chromium-reviews, 2015-12-10 22:20:23]

Will return my CL to see the remaining diffs if any.

On Thu, Dec 10, 2015 at 5:17 PM, <senorblanco@chromium.org> wrote:

> On 2015/12/10 16:19:59, reed1 wrote:
>
>> I think sprite->image cl was blocked on 3 layouttests where the blurs were
>> different. I think those are fixed by your bloat/mapbounds fix. Thus I
>> think
>> your latter 3 steps should work.
>>
>
> OK, I've landed step 1 (the SK_SUPPORT_SRC_BOUNDS_BLOAT_FOR_IMAGEFILTERS
> removal) here:
>
>
https://chromium.googlesource.com/chromium/src/+/d42be13c51bbc3969f2b3b9f9e1c...
>
> https://codereview.chromium.org/1517693002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[blink-reviews, 2015-12-10 22:20:23]

Will return my CL to see the remaining diffs if any.

On Thu, Dec 10, 2015 at 5:17 PM, <senorblanco@chromium.org> wrote:

> On 2015/12/10 16:19:59, reed1 wrote:
>
>> I think sprite->image cl was blocked on 3 layouttests where the blurs were
>> different. I think those are fixed by your bloat/mapbounds fix. Thus I
>> think
>> your latter 3 steps should work.
>>
>
> OK, I've landed step 1 (the SK_SUPPORT_SRC_BOUNDS_BLOAT_FOR_IMAGEFILTERS
> removal) here:
>
>
https://chromium.googlesource.com/chromium/src/+/d42be13c51bbc3969f2b3b9f9e1c...
>
> https://codereview.chromium.org/1517693002/
>

-- 
You received this message because you are subscribed to the Google Groups "Blink
Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[Stephen White, 2016-01-14 16:47:13]

WIP: at patch set #5, layout tests are now all passing (modulo improvements in
correctness and minor pixel diffs).

some cc_unittests are still failing, probably due to background filter outsets
and y_translation calculations.

[Stephen White, 2016-01-19 17:12:17]

Description was changed from

==========
Accelerated filters should filter unpadded primitives.

Skia now has the ability to allocate optimal intermediate buffers
padded by filter-dependent padding. Here we tell Blink not to pad out
for filter outsets, and pass the original (unpadded) primitive to skia
for filtering.

NOTE: this is a WIP. While the intermediate result is correct, the
layer boundaries in cc are wrong (unpadded) with this change,
resulting in an offset image clipped by the (unpadded) primitive size.

BUG=568196
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Accelerated filters should filter unpadded primitives.

Skia now has the ability to allocate optimal intermediate 
buffers padded by filter-dependent padding. Here we tell 
Blink not to pad out filtered layers for filter outsets, 
and compute the optimal bounds in cc via Skia's plumbing. 
This may result in a destination buffer which is of a 
different size than the source, so we modify cc's drawing 
to draw the destination rect.

Also, since we're giving the original (unmodified) source 
rect to Skia, we no longer need to offset the crop rects
in Blink by the delta between the src and dest rects. 
(Note: we can thus remove the crop offset stuff entirely
from Blink, which I'll do in a followup patch.)

Finally, note that the workaround for the 
partially-occupied textures implemented (implemented in 
https://codereview.chromium.org/909353003) was no
longer working when drawing to exact-size textures, due
to a bug in SkAlphaThresholdFilter. This is fixed in Skia 
here:  https://codereview.chromium.org/1609573002/. That 
will be required to roll into Chrome before this patch can
be landed.

BUG=568196
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[Stephen White, 2016-01-19 17:12:17]

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

[Stephen White, 2016-01-19 17:12:29]

senorblanco@chromium.org changed reviewers:
+ enne@chromium.org
- danakj@chromium.org

[Stephen White, 2016-01-19 23:04:11]

enne@: PTAL. Thanks!

[Stephen White, 2016-01-19 23:12:06]

Description was changed from

==========
Accelerated filters should filter unpadded primitives.

Skia now has the ability to allocate optimal intermediate 
buffers padded by filter-dependent padding. Here we tell 
Blink not to pad out filtered layers for filter outsets, 
and compute the optimal bounds in cc via Skia's plumbing. 
This may result in a destination buffer which is of a 
different size than the source, so we modify cc's drawing 
to draw the destination rect.

Also, since we're giving the original (unmodified) source 
rect to Skia, we no longer need to offset the crop rects
in Blink by the delta between the src and dest rects. 
(Note: we can thus remove the crop offset stuff entirely
from Blink, which I'll do in a followup patch.)

Finally, note that the workaround for the 
partially-occupied textures implemented (implemented in 
https://codereview.chromium.org/909353003) was no
longer working when drawing to exact-size textures, due
to a bug in SkAlphaThresholdFilter. This is fixed in Skia 
here:  https://codereview.chromium.org/1609573002/. That 
will be required to roll into Chrome before this patch can
be landed.

BUG=568196
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Accelerated filters should filter unpadded primitives.

Until recently, the Skia image filter infrastructure could
only produce a result image of the same size as its input
image.

For that reason, currently Blink applies filter outsets to 
a layer before it passes the layer to cc. So cc sees a 
layer padded with transparent black out to the filter 
outsets, but has no idea how big the original layer was.
It then passes that to Skia, which produces an image of
the same size.

I've recently fixed Skia to be able to correctly draw from 
the original (unpadded) texture size to the correct, padded 
texture size. But to take advantage of that, we need Blink 
to stop padding the texture (see PaintLayer).

This may result in a destination buffer which is of a 
different size than the source, so we modify cc's drawing 
to draw the destination rect.

Also, since we're giving the original (unmodified) source 
rect to Skia, we no longer need to offset the crop rects
in Blink by the delta between the src and dest rects. 
(Note: we can thus remove the crop offset stuff entirely
from Blink, which I'll do in a followup patch.)

Finally, note that the workaround for the 
partially-occupied textures implemented (implemented in 
https://codereview.chromium.org/909353003) was no
longer working when drawing to exact-size textures, due
to a bug in SkAlphaThresholdFilter. This is fixed in Skia 
here:  https://codereview.chromium.org/1609573002/. That 
will be required to roll into Chrome before this patch can
be landed.

BUG=568196
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[enne (OOO), 2016-01-19 23:21:19]

https://codereview.chromium.org/1517693002/diff/240001/cc/layers/render_surfa...
File cc/layers/render_surface_impl.cc (right):

https://codereview.chromium.org/1517693002/diff/240001/cc/layers/render_surfa...
cc/layers/render_surface_impl.cc:56: drawable_content_rect.Inset(-left, -top,
-right, -bottom);
Should you do this before the replica unioning? What happens if you have a
replica and a blur? Does the replica also get blurred? Or no?

Can you also write a unit test that tests drawable content rect values directly?
I think the pixel test is good, to make sure that gl renderer is correct. 
However, I'd like something that tests this value more directly if you could.  I
think you could take what you do in EnlargedTextureWithCropOffsetFilter and
create a unit test with similar layer tree construction and put it in
layer_tree_host_common_unittest.cc. 
DrawableAndVisibleContentRectsForSurfaceHierarchy is an example to crib from.

Such a test should include a blur of a surface that contains multiple layers (so
that no layer is the entire size of the surface and the whole thing needs to be
expanded), a scale (like you have in the existing test), and maybe with/without
replica.  I think with that, I'd feel confident that nobody would break this in
the future.

https://codereview.chromium.org/1517693002/diff/240001/cc/output/gl_renderer.cc
File cc/output/gl_renderer.cc (right):

https://codereview.chromium.org/1517693002/diff/240001/cc/output/gl_renderer....
cc/output/gl_renderer.cc:653: SkMatrix localM;
localM and localIMF are not chrome style.  Could you fix this as you change
this?

https://codereview.chromium.org/1517693002/diff/240001/cc/output/gl_renderer....
cc/output/gl_renderer.cc:989: if (filter->canComputeFastBounds()) {
What if it can't? Does it just not expand at all? That seems wrong.

[enne (OOO), 2016-01-19 23:21:20]

https://codereview.chromium.org/1517693002/diff/240001/cc/layers/render_surfa...
File cc/layers/render_surface_impl.cc (right):

https://codereview.chromium.org/1517693002/diff/240001/cc/layers/render_surfa...
cc/layers/render_surface_impl.cc:56: drawable_content_rect.Inset(-left, -top,
-right, -bottom);
Should you do this before the replica unioning? What happens if you have a
replica and a blur? Does the replica also get blurred? Or no?

Can you also write a unit test that tests drawable content rect values directly?
I think the pixel test is good, to make sure that gl renderer is correct. 
However, I'd like something that tests this value more directly if you could.  I
think you could take what you do in EnlargedTextureWithCropOffsetFilter and
create a unit test with similar layer tree construction and put it in
layer_tree_host_common_unittest.cc. 
DrawableAndVisibleContentRectsForSurfaceHierarchy is an example to crib from.

Such a test should include a blur of a surface that contains multiple layers (so
that no layer is the entire size of the surface and the whole thing needs to be
expanded), a scale (like you have in the existing test), and maybe with/without
replica.  I think with that, I'd feel confident that nobody would break this in
the future.

https://codereview.chromium.org/1517693002/diff/240001/cc/output/gl_renderer.cc
File cc/output/gl_renderer.cc (right):

https://codereview.chromium.org/1517693002/diff/240001/cc/output/gl_renderer....
cc/output/gl_renderer.cc:653: SkMatrix localM;
localM and localIMF are not chrome style.  Could you fix this as you change
this?

https://codereview.chromium.org/1517693002/diff/240001/cc/output/gl_renderer....
cc/output/gl_renderer.cc:989: if (filter->canComputeFastBounds()) {
What if it can't? Does it just not expand at all? That seems wrong.

[Stephen White, 2016-01-19 23:59:10]

Thanks for your review.

https://codereview.chromium.org/1517693002/diff/240001/cc/layers/render_surfa...
File cc/layers/render_surface_impl.cc (right):

https://codereview.chromium.org/1517693002/diff/240001/cc/layers/render_surfa...
cc/layers/render_surface_impl.cc:56: drawable_content_rect.Inset(-left, -top,
-right, -bottom);
On 2016/01/19 23:21:19, enne wrote:
> Should you do this before the replica unioning? What happens if you have a
> replica and a blur? Does the replica also get blurred? Or no?

Good question. Will investigate.

> Can you also write a unit test that tests drawable content rect values
directly?
> I think the pixel test is good, to make sure that gl renderer is correct. 
> However, I'd like something that tests this value more directly if you could. 
I
> think you could take what you do in EnlargedTextureWithCropOffsetFilter and
> create a unit test with similar layer tree construction and put it in
> layer_tree_host_common_unittest.cc. 
> DrawableAndVisibleContentRectsForSurfaceHierarchy is an example to crib from.
> Such a test should include a blur of a surface that contains multiple layers
(so
> that no layer is the entire size of the surface and the whole thing needs to
be
> expanded), a scale (like you have in the existing test), and maybe
with/without
> replica.  I think with that, I'd feel confident that nobody would break this
in
> the future.

Done.

https://codereview.chromium.org/1517693002/diff/240001/cc/output/gl_renderer.cc
File cc/output/gl_renderer.cc (right):

https://codereview.chromium.org/1517693002/diff/240001/cc/output/gl_renderer....
cc/output/gl_renderer.cc:653: SkMatrix localM;
On 2016/01/19 23:21:19, enne wrote:
> localM and localIMF are not chrome style.  Could you fix this as you change
> this?

Done.

https://codereview.chromium.org/1517693002/diff/240001/cc/output/gl_renderer....
cc/output/gl_renderer.cc:989: if (filter->canComputeFastBounds()) {
On 2016/01/19 23:21:19, enne wrote:
> What if it can't? Does it just not expand at all? That seems wrong.

That's actually current behaviour (even though it's wrong). Getting this right
is part of crbug.com/240845. I'll add a comment.

[Stephen White, 2016-01-20 00:47:29]

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

[commit-bot: I haz the power, 2016-01-20 00:49:02]

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

[Stephen White, 2016-01-20 01:14:28]

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

[commit-bot: I haz the power, 2016-01-20 01:16:19]

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

[commit-bot: I haz the power, 2016-01-20 02:48:54]

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

[commit-bot: I haz the power, 2016-01-20 02:48:55]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Stephen White, 2016-01-20 19:59:01]

New patch up; all tests passing. PTAL.

https://codereview.chromium.org/1517693002/diff/240001/cc/layers/render_surfa...
File cc/layers/render_surface_impl.cc (right):

https://codereview.chromium.org/1517693002/diff/240001/cc/layers/render_surfa...
cc/layers/render_surface_impl.cc:56: drawable_content_rect.Inset(-left, -top,
-right, -bottom);
On 2016/01/19 23:59:10, Stephen White wrote:
> On 2016/01/19 23:21:19, enne wrote:
> > Should you do this before the replica unioning? What happens if you have a
> > replica and a blur? Does the replica also get blurred? Or no?
> 
> Good question. Will investigate.

-webkit-box-reflect is non-standard, and doesn't seem to have a spec, so I
couldn't verify the correct behaviour (unless there's some other way to create a
replica other than -webkit-box-reflect?). I did some tests with drop-shadow and
reflection followed by blur, and it looks better in this patch than in M47 (no
clipping on the edges). Incidentally, it looks like Safari has bugs in this
case: drop-shadow and reflect is fine, but add a blur and the shadow on the
reflection disappears.

Given the general brokenness of reflections in their current state, I'd rather
get this patch in now and address any other issues as they arise.

[enne (OOO), 2016-01-20 22:59:29]

> -webkit-box-reflect is non-standard, and doesn't seem to have a spec, so I
couldn't verify the correct behaviour (unless there's some other way to create a
replica other than -webkit-box-reflect?). I did some tests with drop-shadow and
reflection followed by blur, and it looks better in this patch than in M47 (no
clipping on the edges). Incidentally, it looks like Safari has bugs in this
case: drop-shadow and reflect is fine, but add a blur and the shadow on the
reflection disappears.
> 
> Given the general brokenness of reflections in their current state, I'd rather
get this patch in now and address any other issues as they arise.

Makes sense.  If this is an improvement, then we can sort out other issues
later.

lgtm

https://codereview.chromium.org/1517693002/diff/360001/cc/output/gl_renderer.cc
File cc/output/gl_renderer.cc (right):

https://codereview.chromium.org/1517693002/diff/360001/cc/output/gl_renderer....
cc/output/gl_renderer.cc:1004: // TODO(senorblanco): remove this comment when
http://skbug.com/4627
Thanks for this.  :)

[Stephen White, 2016-01-20 23:00:41]

The CQ bit was checked by senorblanco@chromium.org

[commit-bot: I haz the power, 2016-01-20 23:03:50]

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

[commit-bot: I haz the power, 2016-01-20 23:15:11]

Description was changed from

==========
Accelerated filters should filter unpadded primitives.

Until recently, the Skia image filter infrastructure could
only produce a result image of the same size as its input
image.

For that reason, currently Blink applies filter outsets to 
a layer before it passes the layer to cc. So cc sees a 
layer padded with transparent black out to the filter 
outsets, but has no idea how big the original layer was.
It then passes that to Skia, which produces an image of
the same size.

I've recently fixed Skia to be able to correctly draw from 
the original (unpadded) texture size to the correct, padded 
texture size. But to take advantage of that, we need Blink 
to stop padding the texture (see PaintLayer).

This may result in a destination buffer which is of a 
different size than the source, so we modify cc's drawing 
to draw the destination rect.

Also, since we're giving the original (unmodified) source 
rect to Skia, we no longer need to offset the crop rects
in Blink by the delta between the src and dest rects. 
(Note: we can thus remove the crop offset stuff entirely
from Blink, which I'll do in a followup patch.)

Finally, note that the workaround for the 
partially-occupied textures implemented (implemented in 
https://codereview.chromium.org/909353003) was no
longer working when drawing to exact-size textures, due
to a bug in SkAlphaThresholdFilter. This is fixed in Skia 
here:  https://codereview.chromium.org/1609573002/. That 
will be required to roll into Chrome before this patch can
be landed.

BUG=568196
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Accelerated filters should filter unpadded primitives.

Until recently, the Skia image filter infrastructure could
only produce a result image of the same size as its input
image.

For that reason, currently Blink applies filter outsets to 
a layer before it passes the layer to cc. So cc sees a 
layer padded with transparent black out to the filter 
outsets, but has no idea how big the original layer was.
It then passes that to Skia, which produces an image of
the same size.

I've recently fixed Skia to be able to correctly draw from 
the original (unpadded) texture size to the correct, padded 
texture size. But to take advantage of that, we need Blink 
to stop padding the texture (see PaintLayer).

This may result in a destination buffer which is of a 
different size than the source, so we modify cc's drawing 
to draw the destination rect.

Also, since we're giving the original (unmodified) source 
rect to Skia, we no longer need to offset the crop rects
in Blink by the delta between the src and dest rects. 
(Note: we can thus remove the crop offset stuff entirely
from Blink, which I'll do in a followup patch.)

Finally, note that the workaround for the 
partially-occupied textures implemented (implemented in 
https://codereview.chromium.org/909353003) was no
longer working when drawing to exact-size textures, due
to a bug in SkAlphaThresholdFilter. This is fixed in Skia 
here:  https://codereview.chromium.org/1609573002/. That 
will be required to roll into Chrome before this patch can
be landed.

BUG=568196
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[commit-bot: I haz the power, 2016-01-20 23:15:11]

Committed patchset #20 (id:360001)

[commit-bot: I haz the power, 2016-01-20 23:16:03]

Description was changed from

==========
Accelerated filters should filter unpadded primitives.

Until recently, the Skia image filter infrastructure could
only produce a result image of the same size as its input
image.

For that reason, currently Blink applies filter outsets to 
a layer before it passes the layer to cc. So cc sees a 
layer padded with transparent black out to the filter 
outsets, but has no idea how big the original layer was.
It then passes that to Skia, which produces an image of
the same size.

I've recently fixed Skia to be able to correctly draw from 
the original (unpadded) texture size to the correct, padded 
texture size. But to take advantage of that, we need Blink 
to stop padding the texture (see PaintLayer).

This may result in a destination buffer which is of a 
different size than the source, so we modify cc's drawing 
to draw the destination rect.

Also, since we're giving the original (unmodified) source 
rect to Skia, we no longer need to offset the crop rects
in Blink by the delta between the src and dest rects. 
(Note: we can thus remove the crop offset stuff entirely
from Blink, which I'll do in a followup patch.)

Finally, note that the workaround for the 
partially-occupied textures implemented (implemented in 
https://codereview.chromium.org/909353003) was no
longer working when drawing to exact-size textures, due
to a bug in SkAlphaThresholdFilter. This is fixed in Skia 
here:  https://codereview.chromium.org/1609573002/. That 
will be required to roll into Chrome before this patch can
be landed.

BUG=568196
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Accelerated filters should filter unpadded primitives.

Until recently, the Skia image filter infrastructure could
only produce a result image of the same size as its input
image.

For that reason, currently Blink applies filter outsets to
a layer before it passes the layer to cc. So cc sees a
layer padded with transparent black out to the filter
outsets, but has no idea how big the original layer was.
It then passes that to Skia, which produces an image of
the same size.

I've recently fixed Skia to be able to correctly draw from
the original (unpadded) texture size to the correct, padded
texture size. But to take advantage of that, we need Blink
to stop padding the texture (see PaintLayer).

This may result in a destination buffer which is of a
different size than the source, so we modify cc's drawing
to draw the destination rect.

Also, since we're giving the original (unmodified) source
rect to Skia, we no longer need to offset the crop rects
in Blink by the delta between the src and dest rects.
(Note: we can thus remove the crop offset stuff entirely
from Blink, which I'll do in a followup patch.)

Finally, note that the workaround for the
partially-occupied textures implemented (implemented in
https://codereview.chromium.org/909353003) was no
longer working when drawing to exact-size textures, due
to a bug in SkAlphaThresholdFilter. This is fixed in Skia
here:  https://codereview.chromium.org/1609573002/. That
will be required to roll into Chrome before this patch can
be landed.

BUG=568196
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/38858c57782f2a32cf4f93fcfcc35c340e665be4
Cr-Commit-Position: refs/heads/master@{#370523}
==========

[commit-bot: I haz the power, 2016-01-20 23:16:04]

Patchset 20 (id:??) landed as
https://crrev.com/38858c57782f2a32cf4f93fcfcc35c340e665be4
Cr-Commit-Position: refs/heads/master@{#370523}