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

content/common/webkitplatformsupport_impl.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CONTENT_COMMON_CONTENT_WEBKITPLATFORMSUPPORT_IMPL_H_
 #define CONTENT_COMMON_CONTENT_WEBKITPLATFORMSUPPORT_IMPL_H_
 #pragma once
 
 #include "base/compiler_specific.h"
 #include "content/common/content_export.h"
 #include "webkit/glue/webkitplatformsupport_impl.h"
 
 class GpuChannelHostFactory;
 
+namespace WebKit {
+  class WebView;
+}
+
 namespace content {
 
 // This is a specialization of WebKitPlatformSupportImpl that implements the
 // embedder functions in terms of ContentClient.
 class CONTENT_EXPORT WebKitPlatformSupportImpl
     : NON_EXPORTED_BASE(public webkit_glue::WebKitPlatformSupportImpl) {
  public:
   WebKitPlatformSupportImpl();
   virtual ~WebKitPlatformSupportImpl();
 
   virtual string16 GetLocalizedString(int message_id) OVERRIDE;
   virtual base::StringPiece GetDataResource(int resource_id) OVERRIDE;
   virtual base::StringPiece GetImageResource(int resource_id,
                                              float scale_factor) OVERRIDE;
   virtual void GetPlugins(bool refresh,
                           std::vector<webkit::WebPluginInfo>* plugins) OVERRIDE;
   virtual webkit_glue::ResourceLoaderBridge* CreateResourceLoader(
       const webkit_glue::ResourceLoaderBridge::RequestInfo& request_info)
       OVERRIDE;
   virtual webkit_glue::WebSocketStreamHandleBridge* CreateWebSocketBridge(
       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();
 };
 
 }  // namespace content
 
 #endif  // CONTENT_COMMON_CONTENT_WEBKITPLATFORMSUPPORT_IMPL_H_