Throttle rendering pipeline for invisible iframes

Source/web/WebViewImpl.cpp

Index: Source/web/WebViewImpl.cpp
diff --git a/Source/web/WebViewImpl.cpp b/Source/web/WebViewImpl.cpp
index 7d7ae970d4ac9b0388845d1e5d457848a017e079..44a298fcc3f41498335e826e338cb2a503460174 100644
--- a/Source/web/WebViewImpl.cpp
+++ b/Source/web/WebViewImpl.cpp
@@ -1883,6 +1883,9 @@ void WebViewImpl::beginFrame(const WebBeginFrameArgs& frameTime)
     // FIXME: This should probably be using the local root?
     if (m_page->mainFrame()->isLocalFrame())
         PageWidgetDelegate::animate(*m_page, validFrameTime.lastFrameTimeMonotonic, *m_page->deprecatedLocalMainFrame());
+
+    // HACK: simulate the commit signal for layout tests
+    //Platform::current()->mainThread()->postTask(FROM_HERE, bind(&WebViewImpl::didCommitCompositorFrame, this));
 }
 
 void WebViewImpl::layout()
@@ -1931,6 +1934,14 @@ void WebViewImpl::paint(WebCanvas* canvas, const WebRect& rect)
     Platform::current()->histogramCustomCounts("Renderer4.SoftwarePaintMegapixPerSecond", pixelsPerSec / 1000000, 10, 210, 30);
 }
 
+void WebViewImpl::didCommitCompositorFrame()
+{
+    if (!mainFrameImpl() || !mainFrameImpl()->frameView())
+        return;
+    FrameView* view = mainFrameImpl()->frameView();
+    view->updateThrottling();

[ojan, 2015/09/01 19:56:48]

I was picturing that this would be called unconditionally at the end of
FrameView::updateLifecyclePhasesInternal (in the AllPhases branch at the
bottom). So, WebViewImpl doesn't need to know anything about it.

Is there a reason it needs to be here?

[Sami, 2015/09/02 10:46:03]

Yeah, that was my assumption too but the problem is painting happens after
updateLifecyclePhasesInternal(), so we might try to paint a frame that just
became unthrottled but didn't do a lifecycle update. I'm open to suggestion here
-- maybe this callback should be more painting specific or maybe we do a forced
lifecycle update when unthrottling?

[ojan, 2015/09/02 11:33:27]

Ah right. Doing it synchronously in updateLifecyclePhasesInternal doesn't work.
If we want to match what PositionObserver (now IntersectionObserver) is planning
to do, which I think we do if we can, then we'd do a PostTask from inside
updateLifecyclePhasesInternal. esprehn, does this match your intended direction
for the IntersectionObserver implementation?

[dglazkov, 2015/09/03 16:51:28]

I am still a little bit confused, please forgive me. It seems that
DidCommitCompositorFrame originates from the tail end of the
ThreadProxy::BeginMainFrame
(https://code.google.com/p/chromium/codesearch#chromium/src/cc/trees/thread_pr...),
and the call to WebViewImpl::layout (which is here:
https://code.google.com/p/chromium/codesearch#chromium/src/cc/trees/thread_pr...)
is right before it. Is there something interesting that can happen between these
two that would make any difference?

[Sami, 2015/09/03 19:29:09]

I just gave the PostTask approach a try since you were going to do it for
IntersectionObserver anyway. A small problem is that any tasks (e.g., input
handling) might slip between the lifecycle update and the posted task, which
means that we can't rely on being at in a clean lifecycle state once the task
runs. I think throttling updates can be made to work regardless, but do you
think that's gonna be a problem for IntersectionObserver? Would the explicit
commit signal be better?

+}
+
 #if OS(ANDROID)
 void WebViewImpl::paintCompositedDeprecated(WebCanvas* canvas, const WebRect& rect)
 {