Bug 70160 – [chromium] Route requestAnimationFrame through CCProxy in threaded mode

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Nat Duca]

[chromium] Route requestAnimationFrame through CCProxy in threaded mode

[Nat Duca]

Created attachment 111112 [details]
Patch

[James Robinson]

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?

[Nat Duca]

All great points. Thanks...
(In reply to comment #2)

[Nat Duca]

Created attachment 111681 [details]
Patch for landing

[WebKit Review Bot]

Comment on attachment 111681 [details]
Patch for landing

Clearing flags on attachment: 111681

Committed r97922: <http://trac.webkit.org/changeset/97922>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.