cc: Add threaded GPU rasterization.

cc/output/output_surface.cc

Index: cc/output/output_surface.cc
diff --git a/cc/output/output_surface.cc b/cc/output/output_surface.cc
index 7a0218b0b66abed092b440937a661a3bdebf6f7f..b1a2b9a4647121746fcd342a22d5f2be7d9cd24c 100644
--- a/cc/output/output_surface.cc
+++ b/cc/output/output_surface.cc
@@ -134,21 +134,33 @@ bool OutputSurface::BindToClient(OutputSurfaceClient* client) {
 }
 
 bool OutputSurface::InitializeAndSetContext3d(
-    scoped_refptr<ContextProvider> context_provider) {
+    scoped_refptr<ContextProvider> context_provider,
+    scoped_refptr<ContextProvider> worker_context_provider) {
   DCHECK(!context_provider_.get());
   DCHECK(context_provider.get());
   DCHECK(client_);
 
-  bool success = false;
-  if (context_provider->BindToCurrentThread()) {
+  bool success = context_provider->BindToCurrentThread();
+  if (success) {
     context_provider_ = context_provider;
     SetUpContext3d();
-    client_->DeferredInitialize();
-    success = true;
+  }
+  if (success && worker_context_provider.get()) {
+    success = worker_context_provider->BindToCurrentThread();

[boliu, 2015/02/13 20:25:52]

Was trying this in webview with a ganesh page, and failed in a thread check in
ContextProviderInProcess::ContextGL.

This method is called on the thread, so we can't bind the worker context here
and then use it on a worker thread.

But InitializeAndSetContext3d needs to synchronous return false if this fails.
I'm not sure if it's possible to block the compositor thread on worker threads?

[vmiura, 2015/02/13 21:28:32]

I think I need to implement ContextProviderInProcess::DetachFromThread(), as we
did for ContextProviderCommandBuffer::DetachFromThread().

+    if (success) {
+      worker_context_provider_ = worker_context_provider;
+      // The destructor resets the context lost callback, so base::Unretained
+      // is safe, as long as the worker threads stop using the context before
+      // the output surface is destroyed.
+      worker_context_provider_->SetLostContextCallback(base::Bind(

[boliu, 2015/02/13 20:25:52]

Same threading problem on the context loss callback I think.

[vmiura, 2015/02/13 21:28:32]

Same here.

We bind to the compositor thread here, but then GpuTileTaskWorkerPool
constructor calls ContextProvider::DetachFromThread() to take ownership, and
again in it's destructor to release ownership.

+          &OutputSurface::DidLoseOutputSurface, base::Unretained(this)));
+    }
   }
 
   if (!success)
     ResetContext3d();
+  else
+    client_->DeferredInitialize();
 
   return success;
 }