Integrate custom paint with the DocumentLifecycle

sky/engine/core/page/PageAnimator.cpp

 // 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.
 
 #include "sky/engine/config.h"
 #include "sky/engine/core/page/PageAnimator.h"
 
 #include "sky/engine/core/animation/DocumentAnimations.h"
 #include "sky/engine/core/dom/Document.h"
 #include "sky/engine/core/frame/FrameView.h"
 #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 {
 
 PageAnimator::PageAnimator(Page* page)
     : m_page(page)
     , m_servicingAnimations(false)
     , m_updatingLayoutAndStyleForPainting(false)
 {
 }
@@ skipping 14 matching lines @@
         return;
     m_page->scheduleVisualUpdate();
 }
 
 void PageAnimator::updateLayoutAndStyleForPainting(LocalFrame* rootFrame)
 {
     RefPtr<FrameView> view = rootFrame->view();
 
     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);
 }
 
 }