Add the necessary plumbing mechanisms to ensure proper WebGL support inside the <browser> tag, whic…

content/common/webkitplatformsupport_impl.h

Index: content/common/webkitplatformsupport_impl.h
diff --git a/content/common/webkitplatformsupport_impl.h b/content/common/webkitplatformsupport_impl.h
index c190ae630ac881fc7aa44ed5b19f08d421404926..0998be9824acfb9c223fd67aff156b5326a5e911 100644
--- a/content/common/webkitplatformsupport_impl.h
+++ b/content/common/webkitplatformsupport_impl.h
@@ -12,6 +12,10 @@
 
 class GpuChannelHostFactory;
 
+namespace WebKit {
+  class WebView;
+}
+
 namespace content {
 
 // This is a specialization of WebKitPlatformSupportImpl that implements the
@@ -35,7 +39,8 @@ class CONTENT_EXPORT WebKitPlatformSupportImpl
       WebKit::WebSocketStreamHandle* handle,
       webkit_glue::WebSocketStreamHandleDelegate* delegate) OVERRIDE;
   virtual WebKit::WebGraphicsContext3D* createOffscreenGraphicsContext3D(
-      const WebKit::WebGraphicsContext3D::Attributes& attributes);
+      const WebKit::WebGraphicsContext3D::Attributes& attributes,
+      WebKit::WebView* webView);

[piman, 2012/05/15 20:59:17]

NAK, the offscreen contexts are shared between webviews, so we can't have this
(in theory it's possible to create offscreen contexts without a view, and we
want to keep that behavior).

[(scshunt), 2012/05/16 16:39:43]

See the WebKit bug thread for some discussion of this. The idea here is that the
WebView (or, specifically, the RenderViewImpl) contains the necessary state to
determine whether or not to request the context, not that the context should be
associated with the WebView. The code will work fine without a WebView.

[piman, 2012/05/16 17:12:00]

This is flawed. See the discussion there.
I don't see why you need this. If you're a guest renderer, all your contexts
need to go through pepper. If you're not, all your contexts need to go directly
to the GPU process. Regardless of the webview.

I really suggest you move the webkit changes out of this CL, otherwise it's
going to hold up the part where we're in agreement.
Besides, you'll need to handle the fact that webkit rolls at a different time
than this CL, so even if we settle on changing the interface, you'll need to
have some temporary code for managing the transition without breaking the build.

[Fady Samuel, 2012/05/16 17:40:54]

I agree, let's split this up into two cls.

As for the issue, I'm still trying to figure out why that is? Our current
requirement is a single render process may have many RenderViews, each with a
different embedder process, and hence, multiple GuestToEmbedderChannels, one per
embedder process. If the two embedders are in different SiteInstances, then the
guests should not be able to share texture resources. If the two embedders share
a SiteInstance (share a process), then the guests will automagically share
resources, anyway because they'll be using the one GuestToEmbedderChannel. That
same renderer process may have RenderViews that do not have an embedder and so
their contexts go through the GPU process. I'm waiting on creis@ for some
further clarification but it seems that cross-process navigation is allowed to
reuse old RenderViews, and so a RenderView that had a context directly with the
GPU process may need to drop that context and pick up a pepper context. This is
a fairly complicated problem that I think needs further discussion offline.

 
  protected:
   virtual GpuChannelHostFactory* GetGpuChannelHostFactory();