cc: Add scheduler support for invalidating content on impl thread.

cc/scheduler/scheduler.cc

Index: cc/scheduler/scheduler.cc
diff --git a/cc/scheduler/scheduler.cc b/cc/scheduler/scheduler.cc
index d8f9440227d4b858b6190b63fe3baab87aa513c9..391748dd70805cf21f9610b56c716dc8b5c7a1d1 100644
--- a/cc/scheduler/scheduler.cc
+++ b/cc/scheduler/scheduler.cc
@@ -66,6 +66,11 @@ void Scheduler::Stop() {
   stopped_ = true;
 }
 
+void Scheduler::SetNeedsImplSideInvalidation() {
+  state_machine_.SetNeedsImplSideInvalidation();
+  ProcessScheduledActions();
+}
+
 base::TimeTicks Scheduler::Now() const {
   base::TimeTicks now = base::TimeTicks::Now();
   TRACE_EVENT1(TRACE_DISABLED_BY_DEFAULT("cc.debug.scheduler.now"),
@@ -545,7 +550,8 @@ void Scheduler::OnBeginImplFrameDeadline() {
 
 void Scheduler::DrawIfPossible() {
   bool drawing_with_new_active_tree =
-      state_machine_.active_tree_needs_first_draw();
+      state_machine_.active_tree_needs_first_draw() &&
+      !state_machine_.previous_pending_tree_was_impl_side();

[brianderson, 2017/02/22 19:31:20]

Is there any way to avoid setting active_tree_needs_first_draw in the first
place, rather than canceling it out after the fact?

[Khushal, 2017/02/22 20:19:29]

I think we would want to set |active_tree_needs_first_draw_| to make sure that
this pending tree is pipelined similar to main frames, i.e., don't activate a
new tree until the previous one is drawn.

[brianderson, 2017/02/22 22:58:08]

I think overwriting the active tree in this case might actually be desired to
reduce latency. When a commit comes in while there's still a pending tree, the
two are merged. Would the same thing happen (merging) if the pending tree is
activated when previous_pending_tree_was_impl_side is true?

[Khushal, 2017/02/22 23:20:24]

"When a commit comes in while there's still a pending tree, the
two are merged", do you mean that happens right now? Afaict, if a commit comes
in while there's still a pending tree, the commit has to wait till the pending
tree is activated.

With impl-side invalidations, we defer creating a pending tree if we think a
commit is coming, so we can merge invalidations from both sides on the same
tree. But once created, it is pipelined the same way that a pending tree from
the main thread would have been.

I was more thinking about the case where impl-side invalidations are being used
for an animated gif, in which case you don't want to keep overwriting the active
tree and skipping frames.

[brianderson, 2017/02/22 23:42:33]

I see. I completely misunderstood the merge mechanics. That makes sense now,
especially in the context of the animated gif example.

   bool main_thread_missed_last_deadline =
       state_machine_.main_thread_missed_last_deadline();
   compositor_timing_history_->WillDraw();
@@ -559,7 +565,8 @@ void Scheduler::DrawIfPossible() {
 
 void Scheduler::DrawForced() {
   bool drawing_with_new_active_tree =
-      state_machine_.active_tree_needs_first_draw();
+      state_machine_.active_tree_needs_first_draw() &&
+      !state_machine_.previous_pending_tree_was_impl_side();
   bool main_thread_missed_last_deadline =
       state_machine_.main_thread_missed_last_deadline();
   compositor_timing_history_->WillDraw();
@@ -620,6 +627,10 @@ void Scheduler::ProcessScheduledActions() {
         client_->ScheduledActionActivateSyncTree();
         compositor_timing_history_->DidActivate();
         break;
+      case SchedulerStateMachine::ACTION_PERFORM_IMPL_SIDE_INVALIDATION:
+        state_machine_.WillPerformImplSideInvalidation();
+        client_->ScheduledActionPerformImplSideInvalidation();
+        break;
       case SchedulerStateMachine::ACTION_DRAW_IF_POSSIBLE:
         DrawIfPossible();
         break;