cc: Update Main RendererCapabilities on DeferredInitialize

cc/trees/layer_tree_host_impl.cc

 // Copyright 2011 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.
 
 #include "cc/trees/layer_tree_host_impl.h"
 
 #include <algorithm>
 #include <limits>
 
 #include "base/basictypes.h"
@@ skipping 1857 matching lines @@
   }
 
   if (success) {
     if (offscreen_context_provider.get() &&
         !offscreen_context_provider->BindToCurrentThread())
       success = false;
   }
 
   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()) {
       if (offscreen_context_provider->BindToCurrentThread())
         offscreen_context_provider->VerifyContexts();
       offscreen_context_provider = NULL;
     }
 
     client_->DidLoseOutputSurfaceOnImplThread();
 
@@ skipping 33 matching lines @@
 
   EnforceZeroBudget(true);
   CreateAndSetTileManager(resource_provider_.get(),
                           NULL,
                           GetRendererCapabilities().using_map_image,
                           GetRendererCapabilities().allow_rasterize_on_demand);
   DCHECK(tile_manager_);
 
   SetOffscreenContextProvider(NULL);
 
+  client_->UpdateRendererCapabilitiesOnImplThread();
   client_->SetNeedsCommitOnImplThread();
 }
 
 void LayerTreeHostImpl::SetViewportSize(const gfx::Size& device_viewport_size) {
   if (device_viewport_size == device_viewport_size_)
     return;
 
   if (pending_tree_)
     active_tree_->SetViewportSizeInvalid();
 
@@ skipping 1057 matching lines @@
   swap_promise_monitor_.erase(monitor);
 }
 
 void LayerTreeHostImpl::NotifySwapPromiseMonitorsOfSetNeedsRedraw() {
   std::set<SwapPromiseMonitor*>::iterator it = swap_promise_monitor_.begin();
   for (; it != swap_promise_monitor_.end(); it++)
     (*it)->OnSetNeedsRedrawOnImpl();
 }
 
 }  // namespace cc