Unifies LayerTreeHost::SetNeedsUpdateLayers and SetNeedsAnimate

cc/trees/single_thread_proxy.cc

Index: cc/trees/single_thread_proxy.cc
diff --git a/cc/trees/single_thread_proxy.cc b/cc/trees/single_thread_proxy.cc
index 57f3557e0f5de49b8cd875f9694329b6d80abc2b..1751e62c60f754546aa4c539cc0a6e8e6e5fa519 100644
--- a/cc/trees/single_thread_proxy.cc
+++ b/cc/trees/single_thread_proxy.cc
@@ -176,14 +176,9 @@ const RendererCapabilities& SingleThreadProxy::GetRendererCapabilities() const {
   return renderer_capabilities_for_main_thread_;
 }
 
-void SingleThreadProxy::SetNeedsAnimate() {
-  DCHECK(Proxy::IsMainThread());
-  client_->ScheduleAnimation();
-}
-
 void SingleThreadProxy::SetNeedsUpdateLayers() {
   DCHECK(Proxy::IsMainThread());
-  client_->ScheduleComposite();
+  client_->ScheduleAnimation();

[danakj, 2013/12/05 18:28:16]

Should we be renaming this ScheduleAnimation() function as well?

[trchen, 2013/12/06 03:42:39]

Hmm it may be a good idea. There should be no concept of "layers" in the thread
proxy. +1 vote for it.

[danakj, 2013/12/06 17:21:33]

Ah, sorry for being unclear here. I think SetNeedsUpdateLayers() is the better
name here given that it is the public API, where embedders can request that the
layer they own be updated. "UpdateLayers" is a bit of canonical step in the
compositor flow.

I was referring to the client_->ScheduleAnimation() call here, and wondering if
it should perhaps be client_->ScheduleUpdateLayers? But I am not sure, I think
it would be a follow up patch if anything. I think a comment here why
SetNeedsUpdateLayers is calling ScheduleAnimation would be valuable.

 }
 
 void SingleThreadProxy::DoCommit(scoped_ptr<ResourceUpdateQueue> queue) {