Making scheduler run ANIMATE after a COMMIT (instead of LayerTreeHostImpl).

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 d7f57f2a981704294128f4a7404b0b92f0063988..77ebfdf3b93b82c636f18c6fbd79f971229a08d2 100644
--- a/cc/trees/layer_tree_host_impl.cc
+++ b/cc/trees/layer_tree_host_impl.cc
@@ -336,6 +336,10 @@ void LayerTreeHostImpl::BeginCommit() {
 void LayerTreeHostImpl::CommitComplete() {
   TRACE_EVENT0("cc", "LayerTreeHostImpl::CommitComplete");
 
+  // Ask to be animated if there are animations

[mithro-old, 2014/10/15 07:18:19]

These lines appear to be the cause of the hang issue in
https://code.google.com/p/chromium/issues/detail?id=421931. I'm still trying to
figure out the exact cause though.

[Sami, 2014/10/20 09:44:04]

Sorry for missing this in the review :( This is weird since I'd think the *lack*
of calls to SetNeedsAnimate would cause hangs. I suspect the reason is related
to how we signal the beginning and end of animations to JS somehow. I ran into a
similar but opposite issue when originally splitting animating and drawing:
https://codereview.chromium.org/206793003/

[brianderson, 2014/10/20 18:05:05]

These lines really shouldn't have caused us to hang. It is likely that it's only
causing us to hit an existing bug more often.

We should try to fix ToT so it can work with these lines in and then see if it
fixes the other hangs we are seeing in earlier versions of Chrome.

+  if (needs_animate_layers())
+    SetNeedsAnimate();
+
   if (pending_tree_)
     pending_tree_->ApplyScrollDeltasSinceBeginMainFrame();
   sync_tree()->set_needs_update_draw_properties();