Don't pass subpixel offsets through non-translation transforms

Don't pass subpixel offsets through non-translation transforms

Non-translation transforms will change direction and/or scale, etc.
of offsets thus making subpixel accumulation through the transform
meaningless.

This CL addresses the issue in PaintLayerPainter and
PaintPropertyTreeBuilder. We still need to address the issue in
CompositedLayerMapping (crbug.com/716163).

BUG=710665
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2847873002
Cr-Commit-Position: refs/heads/master@{#468516}
Committed: https://chromium.googlesource.com/chromium/src/+/098430b33423191b06dc32f13de764076cf60394

[Xianzhu, 2017-04-27 22:01:18]

Description was changed from

==========
Don't pass subpixel offsets through non-translation transforms

Non-translation transforms will change direction and/or scale, etc.
of offsets thus making subpixel accumulation through the transform
meaningless.

This CL addresses the issue in PaintLayerPainter and
PaintPropertyTreeBuilder. We still need to address the issue in
CompositedLayerMapping (crbug.com/716163).

BUG=710665
==========

to

==========
Don't pass subpixel offsets through non-translation transforms

Non-translation transforms will change direction and/or scale, etc.
of offsets thus making subpixel accumulation through the transform
meaningless.

This CL addresses the issue in PaintLayerPainter and
PaintPropertyTreeBuilder. We still need to address the issue in
CompositedLayerMapping (crbug.com/716163).

BUG=710665
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

[Xianzhu, 2017-04-27 22:30:15]

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

[commit-bot: I haz the power, 2017-04-27 22:31:31]

Dry run: CQ is trying da patch.

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

[Xianzhu, 2017-04-27 22:53:56]

https://codereview.chromium.org/2847873002/diff/20001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/virtual/disable-spinvalidation/paint/invalidation/subpixel-offset-scaled-transform-expected.txt
(right):

https://codereview.chromium.org/2847873002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/virtual/disable-spinvalidation/paint/invalidation/subpixel-offset-scaled-transform-expected.txt:16:
"rect": [23, 8, 41, 40],
*This is disable-spinvalidation*.

The invalidation rect is incorrect or inconsistent with where we paint the
child. The child is painted at (8,8 40x40) and (8.3,8 40x40) before and after
repaintTest, respectively. The local offset (0.4, 0) is rounded off when
snapping to "pixels" in the child's space during painting.

The invalidation rect is from the slow path (MapToVisualRectInAncestorSpace())
in PaintInvalidationState.

                   PaintInvalidator  MapToVisualRectInAncestorSpace
LocalVisualRect    (0,0 1x1)         (0,0 1x1)
+local offset      (0.4,0 1x1)       (0.4,0 1x1)
EnclosingIntRect   (0,0 2x1)
Transformed        (0,0 80x40)       (~15,0 40x40)
EnclosingBoundingBox                 (~15,0 41x40)
+container offset  (8.3,8 80x40)     (~23,8 41x40)

The difference comes from the EnclosingIntRect step. Should we call
EnclosingIntRect() before applying transform in MapToVisualRectInAncestorSpace?
It was changed to EnclosingBoundingRect after transform in
https://codereview.chromium.org/2727093002.

[Xianzhu, 2017-04-27 23:06:58]

wangxianzhu@chromium.org changed reviewers:
+ chrishtr@chromium.org

[chrishtr, 2017-04-27 23:12:39]

Looks good, but please add a test that exercises the composited transform path.
I think you'll need to adjust corresponding code in
CompositedLayerMapping/PaintLayer
to get the same effect.

[Xianzhu, 2017-04-28 00:14:59]

On 2017/04/27 23:12:39, chrishtr wrote:
> Looks good, but please add a test that exercises the composited transform
path.
> I think you'll need to adjust corresponding code in
> CompositedLayerMapping/PaintLayer
> to get the same effect.

I would like to add tests for the composited issue and address it in another
patch. I filed crbug.com/716163 for it.

What do you think about my question:
https://codereview.chromium.org/2847873002/diff/20001/third_party/WebKit/Layo...

[commit-bot: I haz the power, 2017-04-28 01:37:39]

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

[commit-bot: I haz the power, 2017-04-28 01:37:39]

Dry run: Try jobs failed on following builders:
  linux_layout_tests_slimming_paint_v2 on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_layout_te...)

[chrishtr, 2017-04-28 02:23:50]

On 2017/04/28 at 00:14:59, wangxianzhu wrote:
> On 2017/04/27 23:12:39, chrishtr wrote:
> > Looks good, but please add a test that exercises the composited transform
path.
> > I think you'll need to adjust corresponding code in
> > CompositedLayerMapping/PaintLayer
> > to get the same effect.
> 
> I would like to add tests for the composited issue and address it in another
patch. I filed crbug.com/716163 for it.

As long as it happens in the same Chrome release, ok.

> 
> What do you think about my question:
https://codereview.chromium.org/2847873002/diff/20001/third_party/WebKit/Layo...

[chrishtr, 2017-04-28 02:23:53]

https://codereview.chromium.org/2847873002/diff/20001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/virtual/disable-spinvalidation/paint/invalidation/subpixel-offset-scaled-transform-expected.txt
(right):

https://codereview.chromium.org/2847873002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/virtual/disable-spinvalidation/paint/invalidation/subpixel-offset-scaled-transform-expected.txt:16:
"rect": [23, 8, 41, 40],
On 2017/04/27 at 22:53:55, Xianzhu wrote:
> *This is disable-spinvalidation*.
> 
> The invalidation rect is incorrect or inconsistent with where we paint the
child. The child is painted at (8,8 40x40) and (8.3,8 40x40) before and after
repaintTest, respectively. The local offset (0.4, 0) is rounded off when
snapping to "pixels" in the child's space during painting.
> 
> The invalidation rect is from the slow path (MapToVisualRectInAncestorSpace())
in PaintInvalidationState.
> 
>                    PaintInvalidator  MapToVisualRectInAncestorSpace
> LocalVisualRect    (0,0 1x1)         (0,0 1x1)
> +local offset      (0.4,0 1x1)       (0.4,0 1x1)
> EnclosingIntRect   (0,0 2x1)
> Transformed        (0,0 80x40)       (~15,0 40x40)
> EnclosingBoundingBox                 (~15,0 41x40)
> +container offset  (8.3,8 80x40)     (~23,8 41x40)
> 
> The difference comes from the EnclosingIntRect step. Should we call
EnclosingIntRect() before applying transform in MapToVisualRectInAncestorSpace?
It was changed to EnclosingBoundingRect after transform in
https://codereview.chromium.org/2727093002.

I think in general it has to be that way, at least for non-spinvalidation,
because the paint
offset is not known, so invalidations for 2D transforms that are "identity or
translation" would
incur under-invalidations.

[Xianzhu, 2017-04-28 19:35:28]

https://codereview.chromium.org/2847873002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):

https://codereview.chromium.org/2847873002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1248:
FloatQuad(transform_state.LastPlanarQuad().EnclosingBoundingBox()));
I'm not sure if this is correct:
1. Is it OK to flatten before applying the transform?
2. What if preserve3D and the painter snaps to pixels?

[Xianzhu, 2017-04-28 19:35:45]

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

[commit-bot: I haz the power, 2017-04-28 19:36:52]

Dry run: CQ is trying da patch.

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

[chrishtr, 2017-04-28 19:52:03]

On 2017/04/28 at 19:35:28, wangxianzhu wrote:
>
https://codereview.chromium.org/2847873002/diff/40001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):
> 
>
https://codereview.chromium.org/2847873002/diff/40001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/layout/LayoutBox.cpp:1248:
FloatQuad(transform_state.LastPlanarQuad().EnclosingBoundingBox()));
> I'm not sure if this is correct:
> 1. Is it OK to flatten before applying the transform?

Only if preserve3D is false.

> 2. What if preserve3D and the painter snaps to pixels?

If preserve3D is true and it matters (i.e. there is a 3D transform), then this
is not an SPv1 use-case. This code is just for SPv1 right?

[Xianzhu, 2017-04-28 20:42:13]

On 2017/04/28 19:52:03, chrishtr wrote:
> On 2017/04/28 at 19:35:28, wangxianzhu wrote:
> >
>
https://codereview.chromium.org/2847873002/diff/40001/third_party/WebKit/Sour...
> > File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):
> > 
> >
>
https://codereview.chromium.org/2847873002/diff/40001/third_party/WebKit/Sour...
> > third_party/WebKit/Source/core/layout/LayoutBox.cpp:1248:
> FloatQuad(transform_state.LastPlanarQuad().EnclosingBoundingBox()));
> > I'm not sure if this is correct:
> > 1. Is it OK to flatten before applying the transform?
>
> Only if preserve3D is false.
> 
> > 2. What if preserve3D and the painter snaps to pixels?
> 
> If preserve3D is true and it matters (i.e. there is a 3D transform), then this
> is not an SPv1 use-case. This code is just for SPv1 right?

For the purpose of visual rect calculation for paint invalidation, this code is
just for SPv1 (including SPInvalidation).

For non-paint-invalidation purposes, the function is also used on SPv2, called
from LayoutObject::SelectionRectInViewCoordinates(),
LayoutObject::AbsoluteVisualRect() etc. Whether the rect covers snapped pixels
might be insiginificant.

Is preserve3D always false for SPv1?

[chrishtr, 2017-04-28 20:49:28]

On 2017/04/28 at 20:42:13, wangxianzhu wrote:
> On 2017/04/28 19:52:03, chrishtr wrote:
> > On 2017/04/28 at 19:35:28, wangxianzhu wrote:
> > >
> >
https://codereview.chromium.org/2847873002/diff/40001/third_party/WebKit/Sour...
> > > File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):
> > > 
> > >
> >
https://codereview.chromium.org/2847873002/diff/40001/third_party/WebKit/Sour...
> > > third_party/WebKit/Source/core/layout/LayoutBox.cpp:1248:
> > FloatQuad(transform_state.LastPlanarQuad().EnclosingBoundingBox()));
> > > I'm not sure if this is correct:
> > > 1. Is it OK to flatten before applying the transform?
> >
> > Only if preserve3D is false.
> > 
> > > 2. What if preserve3D and the painter snaps to pixels?
> > 
> > If preserve3D is true and it matters (i.e. there is a 3D transform), then
this
> > is not an SPv1 use-case. This code is just for SPv1 right?
> 
> For the purpose of visual rect calculation for paint invalidation, this code
is just for SPv1 (including SPInvalidation).
> 
> For non-paint-invalidation purposes, the function is also used on SPv2, called
from LayoutObject::SelectionRectInViewCoordinates(),
LayoutObject::AbsoluteVisualRect() etc. Whether the rect covers snapped pixels
might be insiginificant.

It matters, but for SPv2 and SPInvalidation we have an accurate paint offset
pre-computed, so I think we should be able to
compute the exact answer if needed.

> 
> Is preserve3D always false for SPv1?

No, but 3D transforms are irrelevant to SPv1 paint invalidation, because they
never cross paint invalidation containers.

[Xianzhu, 2017-04-28 22:28:33]

Does the CL look good to you?

On 2017/04/28 20:49:28, chrishtr wrote:
> On 2017/04/28 at 20:42:13, wangxianzhu wrote:
> > On 2017/04/28 19:52:03, chrishtr wrote:
> > > On 2017/04/28 at 19:35:28, wangxianzhu wrote:
> > > >
> > >
>
https://codereview.chromium.org/2847873002/diff/40001/third_party/WebKit/Sour...
> > > > File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):
> > > > 
> > > >
> > >
>
https://codereview.chromium.org/2847873002/diff/40001/third_party/WebKit/Sour...
> > > > third_party/WebKit/Source/core/layout/LayoutBox.cpp:1248:
> > > FloatQuad(transform_state.LastPlanarQuad().EnclosingBoundingBox()));
> > > > I'm not sure if this is correct:
> > > > 1. Is it OK to flatten before applying the transform?
> > >
> > > Only if preserve3D is false.
> > > 
> > > > 2. What if preserve3D and the painter snaps to pixels?
> > > 
> > > If preserve3D is true and it matters (i.e. there is a 3D transform), then
> this
> > > is not an SPv1 use-case. This code is just for SPv1 right?
> > 
> > For the purpose of visual rect calculation for paint invalidation, this code
> is just for SPv1 (including SPInvalidation).
> > 
> > For non-paint-invalidation purposes, the function is also used on SPv2,
called
> from LayoutObject::SelectionRectInViewCoordinates(),
> LayoutObject::AbsoluteVisualRect() etc. Whether the rect covers snapped pixels
> might be insiginificant.
> 
> It matters, but for SPv2 and SPInvalidation we have an accurate paint offset
> pre-computed, so I think we should be able to
> compute the exact answer if needed.
> 

Do you mean we should switch the coordinate mapping functions to using
GeometryMapper/paint-properties in the future? I wonder if we have cases that
the functions are needed before PrePaint.

Anyway this CL seems to not cause any regressions about this.

> > 
> > Is preserve3D always false for SPv1?
> 
> No, but 3D transforms are irrelevant to SPv1 paint invalidation, because they
> never cross paint invalidation containers.

[Xianzhu, 2017-04-28 22:59:44]

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

[commit-bot: I haz the power, 2017-04-28 23:00:29]

Dry run: CQ is trying da patch.

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

[chrishtr, 2017-04-28 23:25:25]

On 2017/04/28 at 22:28:33, wangxianzhu wrote:
> Does the CL look good to you?
> 
> On 2017/04/28 20:49:28, chrishtr wrote:
> > On 2017/04/28 at 20:42:13, wangxianzhu wrote:
> > > On 2017/04/28 19:52:03, chrishtr wrote:
> > > > On 2017/04/28 at 19:35:28, wangxianzhu wrote:
> > > > >
> > > >
> >
https://codereview.chromium.org/2847873002/diff/40001/third_party/WebKit/Sour...
> > > > > File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):
> > > > > 
> > > > >
> > > >
> >
https://codereview.chromium.org/2847873002/diff/40001/third_party/WebKit/Sour...
> > > > > third_party/WebKit/Source/core/layout/LayoutBox.cpp:1248:
> > > > FloatQuad(transform_state.LastPlanarQuad().EnclosingBoundingBox()));
> > > > > I'm not sure if this is correct:
> > > > > 1. Is it OK to flatten before applying the transform?
> > > >
> > > > Only if preserve3D is false.
> > > > 
> > > > > 2. What if preserve3D and the painter snaps to pixels?
> > > > 
> > > > If preserve3D is true and it matters (i.e. there is a 3D transform),
then
> > this
> > > > is not an SPv1 use-case. This code is just for SPv1 right?
> > > 
> > > For the purpose of visual rect calculation for paint invalidation, this
code
> > is just for SPv1 (including SPInvalidation).
> > > 
> > > For non-paint-invalidation purposes, the function is also used on SPv2,
called
> > from LayoutObject::SelectionRectInViewCoordinates(),
> > LayoutObject::AbsoluteVisualRect() etc. Whether the rect covers snapped
pixels
> > might be insiginificant.
> > 
> > It matters, but for SPv2 and SPInvalidation we have an accurate paint offset
> > pre-computed, so I think we should be able to
> > compute the exact answer if needed.
> > 
> 
> Do you mean we should switch the coordinate mapping functions to using
GeometryMapper/paint-properties in the future? I wonder if we have cases that
the functions are needed before PrePaint.
> 
> Anyway this CL seems to not cause any regressions about this.

No, I just mean that we have a means of making it accurate in cases involving 3D
if necessary.

> 
> > > 
> > > Is preserve3D always false for SPv1?
> > 
> > No, but 3D transforms are irrelevant to SPv1 paint invalidation, because
they
> > never cross paint invalidation containers.

[chrishtr, 2017-04-28 23:26:44]

https://codereview.chromium.org/2847873002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):

https://codereview.chromium.org/2847873002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1241: // Use
EnclosingBoundingBox because we cannot properly compute pixel
Why does this have to be first now? Don't see it yet.

[commit-bot: I haz the power, 2017-04-29 00:13:15]

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

[commit-bot: I haz the power, 2017-04-29 00:13:16]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Xianzhu, 2017-05-01 18:13:43]

https://codereview.chromium.org/2847873002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):

https://codereview.chromium.org/2847873002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1241: // Use
EnclosingBoundingBox because we cannot properly compute pixel
On 2017/04/28 23:26:44, chrishtr wrote:
> Why does this have to be first now? Don't see it yet.

This is to fix the MapToVisualRectInAncestorSpace() problem described in #4. I
thought you agreed the solution, no?

[chrishtr, 2017-05-01 20:22:28]

https://codereview.chromium.org/2847873002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):

https://codereview.chromium.org/2847873002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1204: // 6. Transform
flattening.
Not an issue you created, but could you make this change?

s/Transform flattening/Transform+flattening/

https://codereview.chromium.org/2847873002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1241: // Use
EnclosingBoundingBox because we cannot properly compute pixel
On 2017/05/01 at 18:13:42, Xianzhu wrote:
> On 2017/04/28 23:26:44, chrishtr wrote:
> > Why does this have to be first now? Don't see it yet.
> 
> This is to fix the MapToVisualRectInAncestorSpace() problem described in #4. I
thought you agreed the solution, no?

Oh I see. Yes I did make this change in 2727093002; fixing it to be back the way
it was in non-preserve3d
makes sense.

https://codereview.chromium.org/2847873002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1244: // include a scale.
Please add a comment saying that pixel-snapping like this only makes sense
for non-preserve3D, and also that it's applicable only for SPv1
paint invalidation use cases, which have no preserve3D.

https://codereview.chromium.org/2847873002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1246:
transform_state.Flatten();
if (!preserve3D && !RuntimeEnabledFeatures::slimmingPaintV2Enabled())

[Xianzhu, 2017-05-01 22:03:32]

https://codereview.chromium.org/2847873002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):

https://codereview.chromium.org/2847873002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1204: // 6. Transform
flattening.
On 2017/05/01 20:22:28, chrishtr wrote:
> Not an issue you created, but could you make this change?
> 
> s/Transform flattening/Transform+flattening/

The steps 1 to 4 are actually generate the transform to be applied in step 6, so
I changed the steps to one step "Generate transform" and sub-steps under the
step.

Also moved step 5 to step 1 because it actually a preparation before applying
transform.

https://codereview.chromium.org/2847873002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1244: // include a scale.
On 2017/05/01 20:22:28, chrishtr wrote:
> Please add a comment saying that pixel-snapping like this only makes sense
> for non-preserve3D, and also that it's applicable only for SPv1
> paint invalidation use cases, which have no preserve3D.

Done.

https://codereview.chromium.org/2847873002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1246:
transform_state.Flatten();
On 2017/05/01 20:22:28, chrishtr wrote:
> if (!preserve3D && !RuntimeEnabledFeatures::slimmingPaintV2Enabled())

Done.

[chrishtr, 2017-05-01 22:13:42]

lgtm

https://codereview.chromium.org/2847873002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):

https://codereview.chromium.org/2847873002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1200: // 2. Generate
transformation matrix by combining:
"combining, in this order"

[Xianzhu, 2017-05-01 22:59:24]

https://codereview.chromium.org/2847873002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):

https://codereview.chromium.org/2847873002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1200: // 2. Generate
transformation matrix by combining:
On 2017/05/01 22:13:42, chrishtr wrote:
> "combining, in this order"

Done.

[Xianzhu, 2017-05-01 22:59:36]

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

[commit-bot: I haz the power, 2017-05-01 23:00:28]

Dry run: CQ is trying da patch.

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

[Xianzhu, 2017-05-01 23:02:03]

The CQ bit was unchecked by wangxianzhu@chromium.org

[Xianzhu, 2017-05-01 23:02:07]

The CQ bit was checked by wangxianzhu@chromium.org

[Xianzhu, 2017-05-01 23:02:08]

The patchset sent to the CQ was uploaded after l-g-t-m from
chrishtr@chromium.org
Link to the patchset: https://codereview.chromium.org/2847873002/#ps120001
(title: "-")

[commit-bot: I haz the power, 2017-05-01 23:03:38]

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, 2017-05-02 00:52:58]

CQ is committing da patch.

Bot data: {"patchset_id": 120001, "attempt_start_ts": 1493679727898130,
"parent_rev": "2915191f0a64f34fcdf8c4e4a0a5d89b2271d816", "commit_rev":
"098430b33423191b06dc32f13de764076cf60394"}

[commit-bot: I haz the power, 2017-05-02 00:53:11]

Description was changed from

==========
Don't pass subpixel offsets through non-translation transforms

Non-translation transforms will change direction and/or scale, etc.
of offsets thus making subpixel accumulation through the transform
meaningless.

This CL addresses the issue in PaintLayerPainter and
PaintPropertyTreeBuilder. We still need to address the issue in
CompositedLayerMapping (crbug.com/716163).

BUG=710665
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

to

==========
Don't pass subpixel offsets through non-translation transforms

Non-translation transforms will change direction and/or scale, etc.
of offsets thus making subpixel accumulation through the transform
meaningless.

This CL addresses the issue in PaintLayerPainter and
PaintPropertyTreeBuilder. We still need to address the issue in
CompositedLayerMapping (crbug.com/716163).

BUG=710665
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2847873002
Cr-Commit-Position: refs/heads/master@{#468516}
Committed:
https://chromium.googlesource.com/chromium/src/+/098430b33423191b06dc32f13de7...
==========

[commit-bot: I haz the power, 2017-05-02 00:53:12]

Committed patchset #7 (id:120001) as
https://chromium.googlesource.com/chromium/src/+/098430b33423191b06dc32f13de7...

[Xianzhu, 2017-05-03 15:41:41]

A revert of this CL (patchset #7 id:120001) has been created in
https://codereview.chromium.org/2859483004/ by wangxianzhu@chromium.org.

The reason for reverting is: BUG=717882.