Bug 59831 – [chromium] WebView support for async compositing

• Component: New Bugs
• Status: RESOLVED WONTFIX

[Nat Duca]

[chromium] Notify WebViewClient when the compositor context is created/lost

[Nat Duca]

Created attachment 91734 [details]
Patch

[Nat Duca]

The high level goal is to hook compositor contexts' swap buffers complete callback and tell the render_widget about it. This is motivated by the render_widget swapbuffer scheduling issues.

There are two ways to do this:
1. the patch done here
2. add a WebView method "supportsAsyncComposite" and two WebViewClient methods "didComposite/compositeAborted". These methods allow us to override the RenderWidget similarly-named methods in RenderView and route them direclty to WebViewImpl.

I'd prefer to do #2, but I can't get that done until tonight. Darin, do either approaches seem tolerable to you?

[Nat Duca]

Created attachment 91953 [details]
Patch

[Nat Duca]

Created attachment 91987 [details]
Typo.

[James Robinson]

Comment on attachment 91987 [details]
Typo.

View in context: https://bugs.webkit.org/attachment.cgi?id=91987&action=review

I'm not sure we actually need all this.  It seems that the callback exists just to call a function on WebViewClient, which in Chrome is the RenderView - but we can (and do) have a pointer to the RenderView in WebGraphicsContext3DCommandBufferImpl::OnSwapBuffers().  What's the motivation for plumbing these calls through the WebViewImpl?  Do you plan to do additional work when these callbacks are invoked?

> Source/WebKit/chromium/ChangeLog:7
> +

there should be some description here of what is going on

> Source/WebKit/chromium/public/WebViewClient.h:325
> +    // Informs the browser that a compositing call completed.
> +    virtual void didComposite() { }
> +
> +    // Informs the browser that compositing failed, usually due to lost context.
> +    virtual void compositeAborted() { }

Compositor WebGraphicsContext3DCommandBufferImpls can already get a pointer to the associated RenderView directly.  Do we need to add new API for this or can it just make calls through that pointer directly to the RenderView (which is a subclass of RenderWidget)

> Source/WebKit/chromium/src/WebViewImpl.cpp:2587
> +    GraphicsContext3DInternal::extractWebGraphicsContext3D(context)->setSwapBuffersCompleteCallbackCHROMIUM(0);

We need to null this pointer out when the WebViewImpl is destroyed and when the context is reset as well since WebViewImpl does not have exclusive ownership of the compositor GraphicsContext3D, it only has a reference to it.  Overall this feels a little fragile - it seems really easy to have a WebGraphicsContext3DCommandBufferImpl that has a pointer to a stale swapbuffers_complete_callback_.

[Nat Duca]

> I'm not sure we actually need all this.
I'll give it a try and see what happens.

[Nat Duca]

Closing. Will implement this with direct calls from WebGraphicsContext3D->RenderView.