Invalidate paint properties on paint offset changes

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 fc48cab3e05c766569f25454af712a7460b27e11..edd94107371598c8687a3d4745bad1fdb972a15d 100644
--- a/third_party/WebKit/Source/core/layout/LayoutBox.cpp
+++ b/third_party/WebKit/Source/core/layout/LayoutBox.cpp
@@ -1692,6 +1692,13 @@ void LayoutBox::frameRectChanged() {
   // Should check this object for paint invalidation.
   if (!needsLayout())
     setMayNeedPaintInvalidation();
+
+  if (RuntimeEnabledFeatures::slimmingPaintInvalidationEnabled()) {
+    // The overflow clip paint property depends on the frame rect
+    // (see: PaintPropertyTreeBuilder::updateOverflowClip).
+    if (hasOverflowClip() || styleRef().containsPaint() || hasControlClip())
+      setNeedsPaintPropertyUpdate();

[trchen, 2016/12/02 22:32:40]

This feel weird to me. The frameRect.location() should be included in the paint
offset and automatically caught already. frameRect.size() is the size of the
border box, but overflow clip uses the padding box. Do we also unconditionally
invalidate paint properties if border width changes?

[pdr., 2016/12/05 04:31:05]

+1, good catch.

This is hard to fix because we don't currently track whether the overflow clip
rect changes in the general case. I've updated this patch to invalidate
properties if a style change occurs on an overflowclip object with any border
values at all. I don't have data to prove it, but I think this is a reasonable
tradeoff because it's rare to have overflowclip + border + style change.

I added a bunch of tests in OverflowClipRecomputedOnChange.

+  }
 }
 
 bool LayoutBox::intersectsVisibleViewport() const {