cc: Update Main RendererCapabilities on DeferredInitialize

cc/trees/layer_tree_host_impl.cc

Index: cc/trees/layer_tree_host_impl.cc
diff --git a/cc/trees/layer_tree_host_impl.cc b/cc/trees/layer_tree_host_impl.cc
index ec89ddcfd734a055a9cdc9fa4dd9bc60bc870f99..7339ea27ba5dcf93de505bf0090e22b901e4f977 100644
--- a/cc/trees/layer_tree_host_impl.cc
+++ b/cc/trees/layer_tree_host_impl.cc
@@ -1875,6 +1875,7 @@ bool LayerTreeHostImpl::DeferredInitialize(
 
   if (success) {
     EnforceZeroBudget(false);
+    client_->UpdateRendererCapabilitiesOnImplThread();

[enne (OOO), 2014/02/14 20:21:48]

This seems like the wrong place to do this.  Can you do this in
CreateAndSetRenderer? If you move it there, then you don't need to do anything
in SingleThreadProxy either.

[boliu, 2014/02/14 22:03:08]

UpdateRendererCapabilitiesOnImplThread is only used for DeferredInitialize and
ReleaseGL (ie the webview methods). It's updated synchronously for normal
compositor init.

Yes, this is a second path just for webview. :(

Dana proposed adding OutputSurfaceProvider, move the logic of creating the OS to
the embedder, and converge more on this path. But not there yet.

[enne (OOO), 2014/02/14 22:08:49]

Can there be only one?

[boliu, 2014/02/14 22:14:49]

No...webview has the crazy requirement to synchronously initialize/tear down GL
on compositor thread.

[enne (OOO), 2014/02/14 22:19:39]

Sure, but the caps can still be sent back the same way in both paths?

[boliu, 2014/02/14 22:27:30]

So InitializeRenderer has main thread blocked and can update caps synchronously.
I don't want to change that behavior to post back to main thread in this patch.

That being said, we could make it look a bit more consistent in LTHI, and decide
whether to post task or copy in the proxy, depending on if main thread is
blocked. But honestly that feels worse than the two explicit paths... WDYT?

[enne (OOO), 2014/02/14 23:02:27]

Maybe it's just me, but I would rather have CreateAndSetRenderer always send
back caps.

If the main thread is synchronously doing an InitializeRenderer, then it can
also cache the caps itself locally and will get a redundant copy later.  You
could put a comment on the main thread side about this, since it's my opinion
that this is the deprecated path and in some shiny future the compositor thread
will be the initiating party for creating the output surface.

     client_->SetNeedsCommitOnImplThread();
   } else {
     if (offscreen_context_provider.get()) {
@@ -1928,6 +1929,7 @@ void LayerTreeHostImpl::ReleaseGL() {
 
   SetOffscreenContextProvider(NULL);
 
+  client_->UpdateRendererCapabilitiesOnImplThread();
   client_->SetNeedsCommitOnImplThread();
 }