Fix CSS reference filters with negative transformed children.

Fix CSS reference filters with negative transformed children.

[M54 cherry-pick of 5941ecb0aea741b27fea283065b25428588dbe43.]

The software raster path for filters had always used the
bounds top-left corner as the origin for filters. This
doesn't work if the filtered primitive contains a
negative-transformed child, since the saveLayer() bounds
should be negative (non-zero) with respect to the
primitive.

The solution is to pass through the origin explicitly, and
translate to that rather than the bounds origin before
applying the filter. This will determine the origin for
crop rects, lighting positions, etc.

It turns out that there are certain CSS properties (e.g., "outline") which affect the size of the layer, but are not
supposed to affect layout. In cc, we had previously been
using the layer's src_rect origin to offset filter
parameters in order to compensate for clipping, etc, but
this is insufficient to handle "outset", which shows up
in the layer position but shouldn't affect filter origin.

The offset that we want was already being computed
for us in GraphicsLayer::setOffsetFromLayoutObject()),
but not forwarded to cc. I've done so, with the
attendant changes to WebLayer, WebLayerImpl, mojo bindings, struct_traits, cc::Layer, cc::LayerImpl, EffectNode,
RenderSurfaceImpl, and RenderPassDrawQuad. (I wish I
was kidding.)

BUG=638091
TRR=ajuma@chromium.org, chrishtr@chromium.org, mbarbella@chromium.org, sky@chromium.org, wkorman@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://chromium.googlesource.com/chromium/src/+/df20db6b63fb755924ee7540b9b4e0671ebe550b

[Stephen White, 2016-08-31 21:50:29]

Description was changed from

==========
Fix CSS reference filters with negative transformed children.

[M54 cherry-pick of 5941ecb0aea741b27fea283065b25428588dbe43.]

The software raster path for filters had always used the
bounds top-left corner as the origin for filters. This
doesn't work if the filtered primitive contains a
negative-transformed child, since the saveLayer() bounds
should be negative (non-zero) with respect to the
primitive.

The solution is to pass through the origin explicitly, and
translate to that rather than the bounds origin before
applying the filter. This will determine the origin for
crop rects, lighting positions, etc.

It turns out that there are certain CSS properties (e.g., "outline") which
affect the size of the layer, but are not
supposed to affect layout. In cc, we had previously been
using the layer's src_rect origin to offset filter
parameters in order to compensate for clipping, etc, but
this is insufficient to handle "outset", which shows up
in the layer position but shouldn't affect filter origin.

The offset that we want was already being computed
for us in GraphicsLayer::setOffsetFromLayoutObject()),
but not forwarded to cc. I've done so, with the
attendant changes to WebLayer, WebLayerImpl, mojo bindings, struct_traits,
cc::Layer, cc::LayerImpl, EffectNode,
RenderSurfaceImpl, and RenderPassDrawQuad. (I wish I
was kidding.)

BUG=638091
TRR=ajuma@chromium.org, chrishtr@chromium.org, mbarbella@chromium.org,
sky@chromium.org, wkorman@chromium.org
==========

to

==========
Fix CSS reference filters with negative transformed children.

[M54 cherry-pick of 5941ecb0aea741b27fea283065b25428588dbe43.]

The software raster path for filters had always used the
bounds top-left corner as the origin for filters. This
doesn't work if the filtered primitive contains a
negative-transformed child, since the saveLayer() bounds
should be negative (non-zero) with respect to the
primitive.

The solution is to pass through the origin explicitly, and
translate to that rather than the bounds origin before
applying the filter. This will determine the origin for
crop rects, lighting positions, etc.

It turns out that there are certain CSS properties (e.g., "outline") which
affect the size of the layer, but are not
supposed to affect layout. In cc, we had previously been
using the layer's src_rect origin to offset filter
parameters in order to compensate for clipping, etc, but
this is insufficient to handle "outset", which shows up
in the layer position but shouldn't affect filter origin.

The offset that we want was already being computed
for us in GraphicsLayer::setOffsetFromLayoutObject()),
but not forwarded to cc. I've done so, with the
attendant changes to WebLayer, WebLayerImpl, mojo bindings, struct_traits,
cc::Layer, cc::LayerImpl, EffectNode,
RenderSurfaceImpl, and RenderPassDrawQuad. (I wish I
was kidding.)

BUG=638091
TRR=ajuma@chromium.org, chrishtr@chromium.org, mbarbella@chromium.org,
sky@chromium.org, wkorman@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

[Stephen White, 2016-08-31 21:50:29]

Description was changed from

==========
Fix CSS reference filters with negative transformed children.

[M54 cherry-pick of 5941ecb0aea741b27fea283065b25428588dbe43.]

The software raster path for filters had always used the
bounds top-left corner as the origin for filters. This
doesn't work if the filtered primitive contains a
negative-transformed child, since the saveLayer() bounds
should be negative (non-zero) with respect to the
primitive.

The solution is to pass through the origin explicitly, and
translate to that rather than the bounds origin before
applying the filter. This will determine the origin for
crop rects, lighting positions, etc.

It turns out that there are certain CSS properties (e.g., "outline") which
affect the size of the layer, but are not
supposed to affect layout. In cc, we had previously been
using the layer's src_rect origin to offset filter
parameters in order to compensate for clipping, etc, but
this is insufficient to handle "outset", which shows up
in the layer position but shouldn't affect filter origin.

The offset that we want was already being computed
for us in GraphicsLayer::setOffsetFromLayoutObject()),
but not forwarded to cc. I've done so, with the
attendant changes to WebLayer, WebLayerImpl, mojo bindings, struct_traits,
cc::Layer, cc::LayerImpl, EffectNode,
RenderSurfaceImpl, and RenderPassDrawQuad. (I wish I
was kidding.)

BUG=638091
TRR=ajuma@chromium.org, chrishtr@chromium.org, mbarbella@chromium.org,
sky@chromium.org, wkorman@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

to

==========
Fix CSS reference filters with negative transformed children.

[M54 cherry-pick of 5941ecb0aea741b27fea283065b25428588dbe43.]

The software raster path for filters had always used the
bounds top-left corner as the origin for filters. This
doesn't work if the filtered primitive contains a
negative-transformed child, since the saveLayer() bounds
should be negative (non-zero) with respect to the
primitive.

The solution is to pass through the origin explicitly, and
translate to that rather than the bounds origin before
applying the filter. This will determine the origin for
crop rects, lighting positions, etc.

It turns out that there are certain CSS properties (e.g., "outline") which
affect the size of the layer, but are not
supposed to affect layout. In cc, we had previously been
using the layer's src_rect origin to offset filter
parameters in order to compensate for clipping, etc, but
this is insufficient to handle "outset", which shows up
in the layer position but shouldn't affect filter origin.

The offset that we want was already being computed
for us in GraphicsLayer::setOffsetFromLayoutObject()),
but not forwarded to cc. I've done so, with the
attendant changes to WebLayer, WebLayerImpl, mojo bindings, struct_traits,
cc::Layer, cc::LayerImpl, EffectNode,
RenderSurfaceImpl, and RenderPassDrawQuad. (I wish I
was kidding.)

BUG=638091
TRR=ajuma@chromium.org, chrishtr@chromium.org, mbarbella@chromium.org,
sky@chromium.org, wkorman@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[Stephen White, 2016-08-31 21:50:49]

The CQ bit was checked by senorblanco@chromium.org

[commit-bot: I haz the power, 2016-08-31 21:51:11]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-31 21:51:12]

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

[commit-bot: I haz the power, 2016-08-31 21:51:13]

No L-G-T-M from a valid reviewer yet. 
CQ run can only be started by full committers or once the patch has
received an L-G-T-M from a full committer.
Even if an L-G-T-M may have been provided, it was from a non-committer,
_not_ a full super star committer.
See http://www.chromium.org/getting-involved/become-a-committer
Note that this has nothing to do with OWNERS files.

[Stephen White, 2016-08-31 22:00:39]

Description was changed from

==========
Fix CSS reference filters with negative transformed children.

[M54 cherry-pick of 5941ecb0aea741b27fea283065b25428588dbe43.]

The software raster path for filters had always used the
bounds top-left corner as the origin for filters. This
doesn't work if the filtered primitive contains a
negative-transformed child, since the saveLayer() bounds
should be negative (non-zero) with respect to the
primitive.

The solution is to pass through the origin explicitly, and
translate to that rather than the bounds origin before
applying the filter. This will determine the origin for
crop rects, lighting positions, etc.

It turns out that there are certain CSS properties (e.g., "outline") which
affect the size of the layer, but are not
supposed to affect layout. In cc, we had previously been
using the layer's src_rect origin to offset filter
parameters in order to compensate for clipping, etc, but
this is insufficient to handle "outset", which shows up
in the layer position but shouldn't affect filter origin.

The offset that we want was already being computed
for us in GraphicsLayer::setOffsetFromLayoutObject()),
but not forwarded to cc. I've done so, with the
attendant changes to WebLayer, WebLayerImpl, mojo bindings, struct_traits,
cc::Layer, cc::LayerImpl, EffectNode,
RenderSurfaceImpl, and RenderPassDrawQuad. (I wish I
was kidding.)

BUG=638091
TRR=ajuma@chromium.org, chrishtr@chromium.org, mbarbella@chromium.org,
sky@chromium.org, wkorman@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Fix CSS reference filters with negative transformed children.

[M54 cherry-pick of 5941ecb0aea741b27fea283065b25428588dbe43.]

The software raster path for filters had always used the
bounds top-left corner as the origin for filters. This
doesn't work if the filtered primitive contains a
negative-transformed child, since the saveLayer() bounds
should be negative (non-zero) with respect to the
primitive.

The solution is to pass through the origin explicitly, and
translate to that rather than the bounds origin before
applying the filter. This will determine the origin for
crop rects, lighting positions, etc.

It turns out that there are certain CSS properties (e.g., "outline") which
affect the size of the layer, but are not
supposed to affect layout. In cc, we had previously been
using the layer's src_rect origin to offset filter
parameters in order to compensate for clipping, etc, but
this is insufficient to handle "outset", which shows up
in the layer position but shouldn't affect filter origin.

The offset that we want was already being computed
for us in GraphicsLayer::setOffsetFromLayoutObject()),
but not forwarded to cc. I've done so, with the
attendant changes to WebLayer, WebLayerImpl, mojo bindings, struct_traits,
cc::Layer, cc::LayerImpl, EffectNode,
RenderSurfaceImpl, and RenderPassDrawQuad. (I wish I
was kidding.)

BUG=638091
TRR=ajuma@chromium.org, chrishtr@chromium.org, mbarbella@chromium.org,
sky@chromium.org, wkorman@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed:
https://chromium.googlesource.com/chromium/src/+/df20db6b63fb755924ee7540b9b4...
==========

[Stephen White, 2016-08-31 22:00:41]

Committed patchset #1 (id:1) manually as
df20db6b63fb755924ee7540b9b4e0671ebe550b.