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

cc/scheduler/scheduler.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/scheduler/scheduler.h"
 
 #include <algorithm>
 
 #include "base/auto_reset.h"
 #include "base/logging.h"
@@ skipping 48 matching lines @@
 }
 
 Scheduler::~Scheduler() {
   SetBeginFrameSource(nullptr);
 }
 
 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"),
                "Scheduler::Now", "now", now);
   return now;
 }
 
 void Scheduler::SetVisible(bool visible) {
   state_machine_.SetVisible(visible);
   UpdateCompositorTimingHistoryRecordingEnabled();
@@ skipping 459 matching lines @@
   //     order to allow the state machine to "settle" first.
   compositor_timing_history_->WillFinishImplFrame(
       state_machine_.needs_redraw());
   state_machine_.OnBeginImplFrameDeadline();
   ProcessScheduledActions();
   FinishImplFrame();
 }
 
 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();
   state_machine_.WillDraw();
   DrawResult result = client_->ScheduledActionDrawIfPossible();
   state_machine_.DidDraw(result);
   compositor_timing_history_->DidDraw(
       drawing_with_new_active_tree, main_thread_missed_last_deadline,
       begin_impl_frame_tracker_.DangerousMethodCurrentOrLast().frame_time);
 }
 
 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();
   state_machine_.WillDraw();
   DrawResult result = client_->ScheduledActionDrawForced();
   state_machine_.DidDraw(result);
   compositor_timing_history_->DidDraw(
       drawing_with_new_active_tree, main_thread_missed_last_deadline,
       begin_impl_frame_tracker_.DangerousMethodCurrentOrLast().frame_time);
 }
@@ skipping 40 matching lines @@
         state_machine_.WillCommit(commit_has_no_updates);
         client_->ScheduledActionCommit();
         break;
       }
       case SchedulerStateMachine::ACTION_ACTIVATE_SYNC_TREE:
         compositor_timing_history_->WillActivate();
         state_machine_.WillActivate();
         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;
       case SchedulerStateMachine::ACTION_DRAW_FORCED:
         DrawForced();
         break;
       case SchedulerStateMachine::ACTION_DRAW_ABORT: {
         // No action is actually performed, but this allows the state machine to
         // drain the pipeline without actually drawing.
         state_machine_.AbortDraw();
@@ skipping 134 matching lines @@
 }
 
 bool Scheduler::IsBeginMainFrameSentOrStarted() const {
   return (state_machine_.begin_main_frame_state() ==
               SchedulerStateMachine::BEGIN_MAIN_FRAME_STATE_SENT ||
           state_machine_.begin_main_frame_state() ==
               SchedulerStateMachine::BEGIN_MAIN_FRAME_STATE_STARTED);
 }
 
 }  // namespace cc