Don't pass subpixel offsets through non-translation transforms

third_party/WebKit/Source/core/layout/LayoutBox.cpp

Index: third_party/WebKit/Source/core/layout/LayoutBox.cpp
diff --git a/third_party/WebKit/Source/core/layout/LayoutBox.cpp b/third_party/WebKit/Source/core/layout/LayoutBox.cpp
index 548907dd20a6eab1e2352cd7e13ca31bc82a21bd..45c06950406da7521b285891732b401c253e2b31 100644
--- a/third_party/WebKit/Source/core/layout/LayoutBox.cpp
+++ b/third_party/WebKit/Source/core/layout/LayoutBox.cpp
@@ -1200,8 +1200,8 @@ bool LayoutBox::MapVisualRectToContainer(
   // 2. Container offset.
   // 3. Container scroll offset.
   // 4. Perspective applied by container.
-  // 5. Transform flattening.
-  // 6. Expansion for pixel snapping.
+  // 5. Expansion for pixel snapping.
+  // 6. Transform flattening.

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

Not an issue you created, but could you make this change?

s/Transform flattening/Transform+flattening/

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

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.

   // 7. Container clip.
 
   // 1. Transform.
@@ -1237,11 +1237,8 @@ bool LayoutBox::MapVisualRectToContainer(
     transform = perspective_matrix * transform;
   }
 
-  // 5. Transform flattening.
-  transform_state.ApplyTransform(transform, accumulation);
-
-  // 6. Expansion for pixel snapping.
-  // Use enclosingBoundingBox because we cannot properly compute pixel
+  // 5. Expansion for pixel snapping.
+  // Use EnclosingBoundingBox because we cannot properly compute pixel

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

Why does this have to be first now? Don't see it yet.

[Xianzhu, 2017/05/01 18:13:42]

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

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

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.

   // snapping for painted elements within the transform since we don't know
   // the desired subpixel accumulation at this point, and the transform may
   // include a scale.

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

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.

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

Done.

@@ -1251,6 +1248,13 @@ bool LayoutBox::MapVisualRectToContainer(
         FloatQuad(transform_state.LastPlanarQuad().EnclosingBoundingBox()));
   }
 
+  // 6. Transform flattening.
+  transform_state.ApplyTransform(transform, accumulation);
+  if (!preserve3D) {
+    transform_state.Flatten();
+    transform_state.SetQuad(FloatQuad(transform_state.LastPlanarQuad()));
+  }
+
   // 7. Container clip.
   if (container_object->IsBox() && container_object != ancestor &&
       container_object->HasClipRelatedProperty()) {