Preparation for enabling slimming paint synchronized painting

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

Index: third_party/WebKit/Source/platform/graphics/paint/PaintController.cpp
diff --git a/third_party/WebKit/Source/platform/graphics/paint/PaintController.cpp b/third_party/WebKit/Source/platform/graphics/paint/PaintController.cpp
index da519217ae7084c3281d03457413fdf805f25d74..51bbe108a1fafcc4745b9155e5492f866d6e8475 100644
--- a/third_party/WebKit/Source/platform/graphics/paint/PaintController.cpp
+++ b/third_party/WebKit/Source/platform/graphics/paint/PaintController.cpp
@@ -124,7 +124,9 @@ void PaintController::invalidate(const DisplayItemClientWrapper& client, PaintIn
 void PaintController::invalidateClient(const DisplayItemClientWrapper& client)
 {
 #if ENABLE(ASSERT)
-    m_invalidations.append(client.debugName());
+    // Slimming paint v1 CompositedLayerMapping may invalidate client on extra layers.

[chrishtr, 2015/10/28 21:12:58]

v2 or v1?

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

v1. For example, in invalidatePaintIncludingNonCompoisitingDescendants(), we may
invalidate a fixed-pos object on a paint invalidation container which the
fixed-pos object doesn't belong to. Here we add into m_invalidations only if the
object has previously cached to avoid ASSERT(m_invalidations.isEmpty()) failure
when a whole GraphicsLayer is cached but something unrelated was invalidated on
the layer.

[chrishtr, 2015/10/29 20:22:45]

Yikes. How does this situation avoid causing the whole GraphicsLayer caching to
fail?

[Xianzhu, 2015/10/30 00:03:57]

Sometimes somehow we also invalidate the object in other paths on the correct
paint invalidation container, so here we ignore the extra one.

Sometimes it's a bug (crbug.com/548495 -- to be fixed by
https://codereview.chromium.org/1413823005/ (WIP)).

[Xianzhu, 2015/10/30 18:05:51]

Also crbug.com/416535.

+    if (RuntimeEnabledFeatures::slimmingPaintV2Enabled() || clientCacheIsValid(client.displayItemClient()))
+        m_invalidations.append(client.debugName());
 #endif
 
     invalidateUntracked(client.displayItemClient());
@@ -278,7 +280,7 @@ void PaintController::commitNewDisplayItems()
         && m_newDisplayItemList.last().type() == DisplayItem::CachedDisplayItemList) {
         // The whole display item list is cached.
         ASSERT(m_newDisplayItemList.size() == 1
-            || (m_newDisplayItemList.size() == 2 && m_newDisplayItemList[0].type() == DisplayItem::DebugRedFill));
+            || (m_newDisplayItemList.size() == 2 && DisplayItem::nonCachedType(m_newDisplayItemList[0].type()) == DisplayItem::DebugRedFill));

[pdr., 2015/10/29 04:06:10]

Why does synchronous painting cause us to hit this codepath with cached debug
red fills whereas we didn't before?

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

This assert is only for CachedDisplayItemList which is a sync painting feature.

         ASSERT(m_invalidations.isEmpty());
         ASSERT(m_clientsCheckedPaintInvalidation.isEmpty());
         m_newDisplayItemList.clear();