Bug 86504 – [Chromium] Expose WebView to graphics context creation.

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

[Sean Hunt]

[Chromium] Expose WebView to graphics context creation.

[Sean Hunt]

Created attachment 142014 [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.

[James Robinson]

What is this for?

[Fady Samuel]

(In reply to comment #3)
> What is this for?

Making shared contexts (WebGL) work in browser plugin guests: see chromium side patch as well if you're interested:

https://chromiumcodereview.appspot.com/10386145

[Sean Hunt]

I don't know how to avoid the downcast to Chrome*. It appears to be safe, but I see no way to guarantee that it is correct or to actually get the Chrome* directly.

[James Robinson]

Comment on attachment 142014 [details]
Patch

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

> Source/WebKit/chromium/public/platform/WebKitPlatformSupport.h:161
> +    virtual WebGraphicsContext3D* createOffscreenGraphicsContext3D(const WebGraphicsContext3D::Attributes&, WebView*) { return 0; };

offscreen contexts are not associated with any WebView, so this is wrong.

[James Robinson]

(In reply to comment #4)
> (In reply to comment #3)
> > What is this for?
> 
> Making shared contexts (WebGL) work in browser plugin guests: see chromium side patch as well if you're interested:
> 
> https://chromiumcodereview.appspot.com/10386145

I can't tell what that patch is trying to do.

Fundamentally this seems broken - offscreen contexts are not associated with any particular WebView.  If this is about forwarding all contexts within a given renderer, then that's something you need to handle yourself externally to WebKit.

[Sean Hunt]

The idea is to create a way for one browser view to interface with another as a plugin. However, when graphics contexts are requested by a plugin, that request must be redirected through the plugin's communications API so that the host process can actually be the one to allocate the graphics context.

The WebView here is not to be associated with the created graphics context, but contains the necessary state to decide the method by which the context should be allocated---either directly, or through the plugin API.

[James Robinson]

(In reply to comment #8)
> The idea is to create a way for one browser view to interface with another as a plugin. However, when graphics contexts are requested by a plugin, that request must be redirected through the plugin's communications API so that the host process can actually be the one to allocate the graphics context.
> 
> The WebView here is not to be associated with the created graphics context, but contains the necessary state to decide the method by which the context should be allocated---either directly, or through the plugin API.

That won't work.  When a context is created it's not associated with any WebView or any state associated with that WebView - it might be used to render anything in the process.  If you want some process-wide state, that can just as easily be stored in a static on the chromium side of the API.

[Fady Samuel]

(In reply to comment #7)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > What is this for?
> > 
> > Making shared contexts (WebGL) work in browser plugin guests: see chromium side patch as well if you're interested:
> > 
> > https://chromiumcodereview.appspot.com/10386145
> 
> I can't tell what that patch is trying to do.
> 
> Fundamentally this seems broken - offscreen contexts are not associated with any particular WebView.  If this is about forwarding all contexts within a given renderer, then that's something you need to handle yourself externally to WebKit.

Reopened. Added kbr: We discussed this a little while ago. Different WebViews share resources with different embedders for offscreen contexts. This patch kind of works. I'm sure we're missing something fundamental. Ken, could you please fill in a little of the details? Thanks

[James Robinson]

The rules for contexts in WebKit are pretty simple:

1.) Onscreen contexts are associated with a WebView and created via that WebView's client.  They can only ever render to that WebView.

2.) Offscreen contexts are not associated with anything and are able to share resources with each other and with any or all onscreen contexts (including ones that don't exist yet when the offscreen context is created).

[Fady Samuel]

(In reply to comment #11)
> The rules for contexts in WebKit are pretty simple:
> 
> 2.) Offscreen contexts are not associated with anything and are able to share resources with each other and with any or all onscreen contexts (including ones that don't exist yet when the offscreen context is created).

But at least for WebGL, we seem to know which WebView is initiating the request. What are other cases where offscreen contexts are created?(In reply to comment #11)
> The rules for contexts in WebKit are pretty simple:
> 

> 2.) Offscreen contexts are not associated with anything and are able to share resources with each other and with any or all onscreen contexts (including ones that don't exist yet when the offscreen context is created).

Within a render process, some WebViews might be guests and some might not be. These should not be sharing offscreen contexts. Why do all Webviews need to share all offscreen contexts?

[James Robinson]

(In reply to comment #12)
> (In reply to comment #11)
> > The rules for contexts in WebKit are pretty simple:
> > 
> > 2.) Offscreen contexts are not associated with anything and are able to share resources with each other and with any or all onscreen contexts (including ones that don't exist yet when the offscreen context is created).
> 
> But at least for WebGL, we seem to know which WebView is initiating the request. What are other cases where offscreen contexts are created?(In reply to comment #11)

Canvas 2d is the case that will probably be most bothersome for you.  For canvas, every canvas context (regardless of WebView) shares one GC3D.  Each canvas context may share a texture with one WebView's context (for compositing) and will definitely share textures with other canvas contexts in the page to do things like draw from one canvas into another canvas.

Even for WebGL I think that the WebView initiating the request is not enough - WebGL canvases can move from one WebView to another and they can use or export resources to canvas or WebGL contexts associated with different WebViews.


> > The rules for contexts in WebKit are pretty simple:
> > 
> 
> > 2.) Offscreen contexts are not associated with anything and are able to share resources with each other and with any or all onscreen contexts (including ones that don't exist yet when the offscreen context is created).
> 
> Within a render process, some WebViews might be guests and some might not be.

I can't see how that would work.

[James Robinson]

> > 
> > Within a render process, some WebViews might be guests and some might not be.
> 
> I can't see how that would work.

Let me expand.  Currently, there's a fair amount of code in WebKit and chromium that makes assumptions about the relationship between WebViews in the same render process - such as assuming that they may synchronously script each other, etc.  Canvas 2d is one example, but not the only one.  If you have some guests in a process with non-guests or different guests then you're breaking this assumption.  Instead, it seems like you would need to define groups of WebViews that have the relationship that being in the same process used to imply, and the propagate that notion to all code in WebKit/chromium that needs to know about this.  It's hard to predict ahead of time everything that you would need to modify to do this.

I'm not sure what lead to the decision to put guest WebViews in the same process as non-guests, but this may be more work than you had in mind.  I'd recommend you start with guests in their own process and get that working first, then see if the refactors for sharing a process are worth the costs.