[SPv2] Track paint offset change

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

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "core/paint/ObjectPainter.h"
 
 #include "core/layout/LayoutBlock.h"
 #include "core/layout/LayoutInline.h"
 #include "core/layout/LayoutObject.h"
 #include "core/layout/LayoutTheme.h"
@@ skipping 676 matching lines @@
   info.phase = PaintPhaseBlockBackground;
   m_layoutObject.paint(info, paintOffset);
   info.phase = PaintPhaseFloat;
   m_layoutObject.paint(info, paintOffset);
   info.phase = PaintPhaseForeground;
   m_layoutObject.paint(info, paintOffset);
   info.phase = PaintPhaseOutline;
   m_layoutObject.paint(info, paintOffset);
 }
 
+#if DCHECK_IS_ON()
+void ObjectPainter::doCheckPaintOffset(const PaintInfo& paintInfo,
+                                       const LayoutPoint& paintOffset) {
+  if (!RuntimeEnabledFeatures::slimmingPaintV2Enabled())
+    return;
+  if (paintInfo.getGlobalPaintFlags() != GlobalPaintNormalPhase)

[pdr., 2016/11/10 07:35:32]

Is this just temporary because you're computing the offset in the paint
invalidation walk? For example, we should still compute the paint offset for
GlobalPaintPrinting, right?

[Xianzhu, 2016/11/10 17:41:10]

Added comments to explain this:

// If we are painting selection, drag-image or printing, we'll paint in ways
// different from the normal painting, which may use paint offsets different
// from those calculated during PrePaintTreeWalk.

[pdr., 2016/11/10 18:54:11]

I don't think this is a blocking issue for this patch, but I am curious about
your thoughts. I thought we would be able to remove the paint offset argument
from the painter classes in spv2, but because of printing we will still need to
keep it? Are the paint offsets for divs/etc really different for painting?

[Xianzhu, 2016/11/10 22:51:50]

Yes. For example, during printing/multicol painting, an object may be painted on
multiple fragments with different paint offsets. Perhaps we should always use
the same paint offset calculated in prepaint by using transforms in the case.

Actually these conditions were added we I was trying the patch on SPv1. The
tests failing on SPv1 may also fail on SPv2 with other reasons. I removed the
conditions. We can notice them when fixing SPv2 failures.

+    return;
+  if (paintInfo.context.getPaintController().isSkippingCache())
+    return;
+  // TODO(pdr): Let painter and paint property tree builder generate the same
+  // paint offset for LayoutScrollbarPart.

[chrishtr, 2016/11/10 18:42:00]

Is there a bug filed for this?

[Xianzhu, 2016/11/10 22:51:50]

pdr@ just filed crbug.com/664249. Added link here.

+  if (m_layoutObject.isLayoutScrollbarPart())
+    return;
+
+  LayoutPoint adjustedPaintOffset = paintOffset;
+  if (m_layoutObject.isBox())
+    adjustedPaintOffset += toLayoutBox(m_layoutObject).location();
+  DCHECK(m_layoutObject.previousPaintOffset() == adjustedPaintOffset);
+}
+#endif
+
 }  // namespace blink