[chromium] Route requestAnimationFrame through CCProxy in threaded mode
Created attachment 111112 [details] Patch
Comment on attachment 111112 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=111112&action=review R=me - have some nits to address while landing. > Source/WebCore/platform/graphics/chromium/cc/CCSingleThreadProxy.cpp:144 > + ASSERT(0); we have ASSERT_NOT_REACHED() for this > Source/WebKit/chromium/src/ChromeClientImpl.cpp:542 > +#if USE(ACCELERATED_COMPOSITING) > + if (!m_webView->isAcceleratedCompositingActive()) > +#endif > + m_webView->client()->scheduleAnimation(); > +#if USE(ACCELERATED_COMPOSITING) > + else > + m_webView->scheduleAnimation(); > +#endif i think things would be slightly cleaner if ChromeClientImpl::scheduleAnimation() simply delegated to m_webView->scheduleAnimation() and all of the #if USE(ACCELE...) etc crap was inside WebViewImpl.cpp. WebViewImpl::scheduleAnimation() call call out to its client if it needs to > Source/WebKit/chromium/src/WebViewImpl.h:-384 > - void doUpdateAndComposite(); guessing this function wasn't actually defined or referenced before?
All great points. Thanks... (In reply to comment #2)
Created attachment 111681 [details] Patch for landing
Comment on attachment 111681 [details] Patch for landing Clearing flags on attachment: 111681 Committed r97922: <http://trac.webkit.org/changeset/97922>
All reviewed patches have been landed. Closing bug.