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

content/renderer/browser_plugin/guest_to_embedder_channel.cc

Index: content/renderer/browser_plugin/guest_to_embedder_channel.cc
diff --git a/content/renderer/browser_plugin/guest_to_embedder_channel.cc b/content/renderer/browser_plugin/guest_to_embedder_channel.cc
index 1f9f6a78b5823b685d9f3b765ef56dd6459e6a87..4cb8bf808554c4eafc6f5e969b9ef481b1c6a36f 100644
--- a/content/renderer/browser_plugin/guest_to_embedder_channel.cc
+++ b/content/renderer/browser_plugin/guest_to_embedder_channel.cc
@@ -164,6 +164,8 @@ bool GuestToEmbedderChannel::CreateGraphicsContext(
   bool success = Send(new PpapiHostMsg_PPBGraphics3D_Create(
       ppapi::API_ID_PPB_GRAPHICS_3D,
       render_view->guest_pp_instance(),
+      offscreen ? render_view->guest_graphics_resource()
+                : ppapi::HostResource(),

[piman, 2012/05/24 23:10:08]

No, you should pass here the WebGraphicsContext3DCommandBufferImpl you're
sharing with, and unwrap it to get to the resource.
you can have several onscreen contexts (say for different renderviews) that need
to share together. Also onscreen vs shared context can be created in any order,
but they need to share with one another.

[(scshunt), 2012/05/24 23:18:07]

I'm going to be changing this up a lot here now that I have a better idea of the
sharing model I think we want to use, so anything here will be temporary anyway.

If I change this into a ppapi::HostResource() in the meanwhile (getting rid of
the conditional), and drop the rest of the file, is this good to go? It would be
good to upstream the rest of this code.

       attribs,
       &resource));
   if (!success || resource.is_null())
@@ -177,6 +179,7 @@ bool GuestToEmbedderChannel::CreateGraphicsContext(
             &result));
     if (result != PP_TRUE)
       return false;
+    render_view->set_guest_graphics_resource(resource);

[piman, 2012/05/24 23:10:08]

err, what if we have more than 1 "onscreen" context per render view? This
happens today during lost context recovery (you may have at the same time the
old context which is lost, and the new one).

[(scshunt), 2012/05/24 23:18:07]

This is actually an unrelated fix, and is an improvement over the old code, but
only slightly. This will probably change now that I think I have a good model of
the sharing model.

[Fady Samuel, 2012/05/24 23:19:00]

PpapiCommandBufferProxy knows about its HostResource. So the old, lost context
will still be able to talk to the embedder.

guest_graphics_resource is only used in RenderViewImpl::DidInitiatePaint to
inform the embedder it should invalidate its browser plugin container.

   }
 
   CommandBufferProxy* command_buffer =
@@ -186,7 +189,6 @@ bool GuestToEmbedderChannel::CreateGraphicsContext(
       command_buffer,
       attributes,
       false /* bind generates resources */);
-  render_view->set_guest_graphics_resource(resource);
   return true;
 }