Round the subpixel accumulation used for composited scrolling content

third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp

Index: third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp
diff --git a/third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp b/third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp
index 1620e00c83d80b1e6f16f8e506d5ffd142c0683d..410ef645fcf0d1303027c2973f8cc6fa744d10f4 100644
--- a/third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp
+++ b/third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp
@@ -320,6 +320,10 @@ PaintResult PaintLayerPainter::paintLayerContents(
       m_paintLayer.compositingState() == PaintsIntoOwnBacking
           ? m_paintLayer.subpixelAccumulation()
           : paintingInfoArg.subPixelAccumulation;
+  // The composited scrolling contents layer position rounds the subpixel
+  // accumulation.
+  if (isPaintingScrollingContent)

[chrishtr, 2017/04/07 21:03:12]

I think you can move the logic determining subpixel accumulation entirely
up into CompositedLayerMapping, and pass it through paintingInfoArg.
Then the conditional on lines 320-322 can be removed, and the code can always
obey paintingInfoArg.subPixelAccumulation.

[flackr, 2017/04/21 03:43:44]

Done. The conditional on 320 was strange since it seems that
paintingInfoArg.subPixelAccumulation is passed in from CLM as the paint layers
subpixel accumulation (i.e. the same value). There are a couple of other
callsites where the passed in accumulation value is (0, 0), so perhaps the
conditional is to make sure we respect the layer accumulation in those cases? In
any event I've added checks to these callsites to see if this change would cause
any accumulation changes, I suspect not, but I'm running tryjobs to see if it
triggers.

+    subpixelAccumulation = LayoutSize(roundedIntSize(subpixelAccumulation));
   ShouldRespectOverflowClipType respectOverflowClip =
       shouldRespectOverflowClip(paintFlags, m_paintLayer.layoutObject());