Integrate custom paint with the DocumentLifecycle

sky/engine/core/page/PageAnimator.cpp

Index: sky/engine/core/page/PageAnimator.cpp
diff --git a/sky/engine/core/page/PageAnimator.cpp b/sky/engine/core/page/PageAnimator.cpp
index 7a147848e963fa9bfbb507e83838734e00d18baa..d16042fb0b8661c0eb24735dccc7357d89d555e7 100644
--- a/sky/engine/core/page/PageAnimator.cpp
+++ b/sky/engine/core/page/PageAnimator.cpp
@@ -11,6 +11,7 @@
 #include "sky/engine/core/frame/LocalFrame.h"
 #include "sky/engine/core/page/ChromeClient.h"
 #include "sky/engine/core/page/Page.h"
+#include "sky/engine/core/painting/PaintingTasks.h"
 #include "sky/engine/platform/Logging.h"
 
 namespace blink {
@@ -45,17 +46,18 @@ void PageAnimator::updateLayoutAndStyleForPainting(LocalFrame* rootFrame)
 
     TemporaryChange<bool> servicing(m_updatingLayoutAndStyleForPainting, true);
 
-    // In order for our child HWNDs (NativeWindowWidgets) to update properly,
-    // they need to be told that we are updating the screen. The problem is that
-    // the native widgets need to recalculate their clip region and not overlap
-    // any of our non-native widgets. To force the resizing, call
-    // setFrameRect(). This will be a quick operation for most frames, but the
-    // NativeWindowWidgets will update a proper clipping region.
     view->setFrameRect(view->frameRect());
+    view->updateLayoutAndStyleForPainting();
 
-    // setFrameRect may have the side-effect of causing existing page layout to
-    // be invalidated, so layout needs to be called last.
+    // TODO(abarth): Remove these calls to updateLayoutAndStyleForPainting
+    // once requestPaint callbacks can't dirty layout.
+    while (PaintingTasks::serviceRequests())
+        view->updateLayoutAndStyleForPainting();
     view->updateLayoutAndStyleForPainting();

[ojan, 2015/03/20 02:35:14]

Is this call needed?

[abarth-chromium, 2015/03/20 02:54:51]

serviceRequests returns if there are more requests, but I can change it to
return true iff the queue is empty, which will let us remove this call and save
the second trip through updateLayoutAndStyleForPainting in the case of not
having any custom painting requests.

[ojan, 2015/03/20 03:38:02]

Don't know if this is intentional, but if you hit the footgun in one of the
paint callbacks inside serviceRequests, then the size of the PaintingContext can
be stale in the following paint callbacks inside serviceRequests. To be 100%
correct, you'd have to call updateLayoutAndStyleForPainting after each callback
in serviceRequests and then create the PaintingContext.

So, I'm not sure the loop here makes sense. Or am I reading the code wrong?

FWIW, in the case of line 56 here, I wasn't worried about performance. I just
thought it was noop code. I see now that it's not because the serviced requests
can dirty style/layout.

+
+    PaintingTasks::drainCommits();
+
+    ASSERT(m_page->mainFrame()->document()->lifecycle().state() == DocumentLifecycle::StyleAndLayoutClean);
 }
 
 }