Store previous painting clip rects on FragmentData.

third_party/WebKit/Source/core/paint/FragmentData.h

Index: third_party/WebKit/Source/core/paint/FragmentData.h
diff --git a/third_party/WebKit/Source/core/paint/FragmentData.h b/third_party/WebKit/Source/core/paint/FragmentData.h
index 8951c3211dc9368fe926015ec3c54cdd90e26938..0eb582b4fac61911a2b408db4dedf61f847fa188 100644
--- a/third_party/WebKit/Source/core/paint/FragmentData.h
+++ b/third_party/WebKit/Source/core/paint/FragmentData.h
@@ -27,12 +27,27 @@ class CORE_EXPORT FragmentData {
   ObjectPaintProperties& EnsurePaintProperties();
   void ClearPaintProperties();
 
+  ClipRects* PreviousPaintingClipRects() const {

[wkorman, 2017/05/01 20:29:24]

Are there other clip rects we expect to store in FragmentData that aren't
painting related? If not we could remove Painting from names.

I see we already have similar named member data and methods in PaintLayer, but I
have same question there. It's a PaintLayer, so I would implicitly default to
assuming clip rects stored or interacted with there are painting related. Do we
need painting in the names?

[chrishtr, 2017/05/01 21:43:54]

Done.

+    DCHECK(RuntimeEnabledFeatures::slimmingPaintInvalidationEnabled());
+    return previous_painting_clip_rects_.Get();
+  }
+  void SetPreviousPaintingClipRects(ClipRects& clip_rects) {
+    previous_painting_clip_rects_ = &clip_rects;
+  }
+  void ClearPreviousPaintingClipRects() {
+    previous_painting_clip_rects_.Clear();
+  }
+
   FragmentData* NextFragment() { return next_fragment_.get(); }
 
  private:
   // Holds references to the paint property nodes created by this object.
   std::unique_ptr<ObjectPaintProperties> paint_properties_;
 
+  // These are used to detect changes to clipping that might invalidate
+  // subsequence caching or paint phase optimizations.
+  RefPtr<ClipRects> previous_painting_clip_rects_;
+
   std::unique_ptr<FragmentData> next_fragment_;
 };