Let synchronized painting generate correct paint invalidation rects

third_party/WebKit/Source/platform/graphics/paint/PaintController.h

 // 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.
 
 #ifndef PaintController_h
 #define PaintController_h
 
 #include "platform/PlatformExport.h"
 #include "platform/RuntimeEnabledFeatures.h"
 #include "platform/geometry/IntRect.h"
@@ skipping 25 matching lines @@
 class PLATFORM_EXPORT PaintController {
     WTF_MAKE_NONCOPYABLE(PaintController);
     WTF_MAKE_FAST_ALLOCATED(PaintController);
 public:
     static PassOwnPtr<PaintController> create()
     {
         return adoptPtr(new PaintController());
     }
 
     // These methods are called during paint invalidation (or paint if SlimmingPaintSynchronizedPainting is on).
-    void invalidate(const DisplayItemClientWrapper&, PaintInvalidationReason, const IntRect& previousPaintInvalidationRect, const IntRect& newPaintInvalidationRect);
+    void invalidate(const DisplayItemClientWrapper&, PaintInvalidationReason, const Vector<IntRect>& paintInvalidationRects);

[chrishtr, 2015/10/22 00:02:41]

If it's a vector, how is Walter's code supposed to know what the new bounds of
the display item are?

[Xianzhu, 2015/10/22 01:17:04]

This is a good question which actually answers my question about how
invalidation rects will be used.

Before this change, we also can't ensure newPaintInvalidationRect to be the
bounding box (see examples below).

We should separate paint invalidation rects from new bounds because not every
invalidation is a full invalidation. For example
- incremental invalidation: I had been thinking of removing it for spv2, but
based on today's discussion about raster invalidation, I think it's still useful
to keep raster invalidation small. (We'll need to keep also the original logics
to reduce rect-based invalidations e.g. [1].)
- rect based invalidations: LayoutObject::invalidatePaintRectangle();
- empty rect (or vector) passed when we just want to invalidate the display item
client.

We may have two methods for paint invalidation:
void invalidateDisplayItemClient(const DisplayItemClientWrapper&, const IntRect&
boundingBox);
void invalidateRect(PaintInvalidationReason, const IntRect& rect);

However, the above seem to only work with invalidation-in-paint because we must
know which PaintChunk the invalidated rect belongs to.

I have a much simpler method to make rect-based invalidation work for spv1
synchronized painting: use the whole original GraphicsLayer-based paint
invalidation. I'd like to leave PaintController rect-based invalidation to spv2.

[1]
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit....

     void invalidateUntracked(DisplayItemClient);
     void invalidateAll();
 
     // Record when paint offsets change during paint.
     void invalidatePaintOffset(const DisplayItemClientWrapper&);
 #if ENABLE(ASSERT)
     bool paintOffsetWasInvalidated(DisplayItemClient) const;
 #endif
 
     // These methods are called during painting.
@@ skipping 198 matching lines @@
     // easily find where the duplicated ids are from.
     DisplayItemIndicesByClientMap m_newDisplayItemIndicesByClient;
 #endif
 
     OwnPtr<Vector<String>> m_trackedPaintInvalidationObjects;
 };
 
 } // namespace blink
 
 #endif // PaintController_h