cc: Implement shared worker contexts. (v1)

content/renderer/render_widget.cc

Index: content/renderer/render_widget.cc
diff --git a/content/renderer/render_widget.cc b/content/renderer/render_widget.cc
index a071d1477ad0e8e6c6e6962b95285a313368c79f..3af2461d10d38c34c786287acffefe6a6101750f 100644
--- a/content/renderer/render_widget.cc
+++ b/content/renderer/render_widget.cc
@@ -1022,10 +1022,13 @@ scoped_ptr<cc::OutputSurface> RenderWidget::CreateOutputSurface(bool fallback) {
 
     worker_context_provider = ContextProviderCommandBuffer::Create(
         CreateGraphicsContext3D(false), RENDER_WORKER_CONTEXT);
-    if (!worker_context_provider.get()) {
+    if (!worker_context_provider.get() ||
+        !worker_context_provider->BindToCurrentThread()) {

[jbauman, 2015/08/26 20:59:25]

I think we want this to happen on the compositor thread, as that's where all the
callbacks will be executed.

[reveman, 2015/08/26 22:02:11]

The idea is that worker context callbacks are instead handled on the current
thread as it can be shared between compositors and other parts of chromium.
Mainly because that easier to setup as the context provider is created here and
not on the compositor thread but also to make it easier to reason about usage
from multiple threads. The context is currently only used on worker threads by
cc/ but could also be used by the media thread in the future and in that case
handling callbacks on the compositor thread seems weird.

       // Cause the compositor to wait and try again.
       return scoped_ptr<cc::OutputSurface>();
     }
+    worker_context_provider->SetupLock();
+    worker_context_provider->DetachFromThread();

[danakj, 2015/08/26 18:48:50]

ditto

[reveman, 2015/08/26 22:02:11]

Done.

   }
 
   uint32 output_surface_id = next_output_surface_id_++;