Bug 99863 – [chromium] API to pass impl thread via WebLayerTreeView

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

[Alexandre Elias]

[chromium] API to pass impl thread via WebLayerTreeView

[Alexandre Elias]

Created attachment 169675 [details]
Patch

[WebKit Review Bot]

Please wait for approval from [e-mail], [e-mail], [e-mail], [e-mail] or [e-mail] before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.

[Alexandre Elias]

Hi James, this is the WebKit side of the change, carefully designed to land first without breaking anything.  After this, I'll make a big Chromium patch switching everything over, then go back to WebKit to delete the cruft.

[James Robinson]

Comment on attachment 169675 [details]
Patch

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

This looks great.

> Source/Platform/chromium/public/WebLayerTreeView.h:75
> +    WEBKIT_EXPORT static WebLayerTreeView* create(WebLayerTreeViewClient*, const WebLayer& root, const Settings&, WebThread* implThread);
> +    // FIXME(aelias): Delete this version when the above is implemented.
>      WEBKIT_EXPORT static WebLayerTreeView* create(WebLayerTreeViewClient*, const WebLayer& root, const Settings&);

Actually both of these ::create()s are dead - in fact all of the ::create() functions for things that hang off of WebCompositorSupport are currently unimplemented and uncalled.  I still haven't deleted them because I suck :(.  Don't worry about patching this file

[Alexandre Elias]

I noticed that, but I actually intend to use the new create() I added.  The reason is that I want to avoid calling compositorSupport() from the browser process.  As part of my Chromium-side change, I'll change the CompositorSupport implementation to use that create() as well to avoid the duplicate code.

[James Robinson]

I don't think that's a good idea - I'm about to delete the whole ::create() family.  There's no way to implement them from inside WebKit.dll and no way to provide exported functions from outside WebKit.dll.  This way lies madness, I tried pretty hard.

What you should do is get an instance of a WebCompositorSupport implementation in your browser code from somewhere other than WebKit::Platform::current() and use the factory functions on it.

[Alexandre Elias]

Created attachment 169681 [details]
Patch

Don't add a new WebLayerTreeView::create

[Alexandre Elias]

Created attachment 169682 [details]
Patch

Remove accidentally added PageWidgetDelegate change

[Alexandre Elias]

OK, makes sense.  Please r+ again.

[WebKit Review Bot]

Comment on attachment 169682 [details]
Patch

Clearing flags on attachment: 169682

Committed r131944: <http://trac.webkit.org/changeset/131944>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[James Robinson]

On further thought, I actually think this is going in the wrong direction - we can't really support different thread modes on different views.