Disable scheduler deadline task on battery power in Windows

cc/scheduler/scheduler.cc

Index: cc/scheduler/scheduler.cc
diff --git a/cc/scheduler/scheduler.cc b/cc/scheduler/scheduler.cc
index 1c66f01ab320d34187eca2bf73b1cad3687e22da..add115d13759f6f2846a5350f887a2fc0d953d72 100644
--- a/cc/scheduler/scheduler.cc
+++ b/cc/scheduler/scheduler.cc
@@ -9,6 +9,7 @@
 #include "base/debug/trace_event.h"
 #include "base/debug/trace_event_argument.h"
 #include "base/logging.h"
+#include "base/power_monitor/power_monitor.h"
 #include "base/single_thread_task_runner.h"
 #include "cc/debug/devtools_instrumentation.h"
 #include "cc/debug/traced_value.h"
@@ -106,12 +107,20 @@ Scheduler::Scheduler(
   advance_commit_state_closure_ = base::Bind(
       &Scheduler::PollToAdvanceCommitState, weak_factory_.GetWeakPtr());
 
+  if (settings_.high_latency_mode_on_battery) {
+    SetupPowerMonitoring();
+  }
+
   if (!settings_.begin_frame_scheduling_enabled) {
     SetupSyntheticBeginFrames();
   }
 }
 
 Scheduler::~Scheduler() {
+  if (settings_.high_latency_mode_on_battery) {
+    TeardownPowerMonitoring();
+  }
+
   if (synthetic_begin_frame_source_) {
     synthetic_begin_frame_source_->SetNeedsBeginFrame(false,
                                                       &begin_retro_frame_args_);
@@ -136,6 +145,23 @@ base::TimeTicks Scheduler::Now() const {
   return gfx::FrameTime::Now();
 }
 
+void Scheduler::SetupPowerMonitoring() {
+  base::PowerMonitor* power_monitor = base::PowerMonitor::Get();
+  DCHECK(power_monitor != NULL);
+  power_monitor->AddObserver(this);
+  on_battery_power_ = power_monitor->IsOnBatteryPower();
+}
+
+void Scheduler::TeardownPowerMonitoring() {
+  base::PowerMonitor* power_monitor = base::PowerMonitor::Get();
+  DCHECK(power_monitor != NULL);
+  power_monitor->RemoveObserver(this);
+}
+
+void Scheduler::OnPowerStateChange(bool on_battery_power) {
+  on_battery_power_ = on_battery_power;
+}
+
 void Scheduler::CommitVSyncParameters(base::TimeTicks timebase,
                                       base::TimeDelta interval) {
   // TODO(brianderson): We should not be receiving 0 intervals.
@@ -506,6 +532,21 @@ void Scheduler::PostBeginRetroFrameIfNeeded() {
   task_runner_->PostTask(FROM_HERE, begin_retro_frame_closure_);
 }
 
+bool Scheduler::ShouldPostBeginImplFrameDeadline() const {
+  // The synchronous renderer compositor has to make its GL calls
+  // within the BeginFrame call stack.
+  // TODO(brianderson): Have the OutputSurface initiate the deadline tasks
+  // so the sychronous renderer compositor can take advantage of splitting
+  // up the BeginImplFrame and deadline as well.
+  if (settings_.using_synchronous_renderer_compositor)
+    return false;
+
+  if (settings_.high_latency_mode_on_battery && on_battery_power_)

[brianderson, 2014/09/12 22:05:27]

Please add a comment above this if.

+    return false;
+
+  return true;
+}
+
 // BeginImplFrame starts a compositor frame that will wait up until a deadline
 // for a BeginMainFrame+activation to complete before it times out and draws
 // any asynchronous animation and scroll/pinch updates.
@@ -514,6 +555,7 @@ void Scheduler::BeginImplFrame(const BeginFrameArgs& args) {
   DCHECK_EQ(state_machine_.begin_impl_frame_state(),
             SchedulerStateMachine::BEGIN_IMPL_FRAME_STATE_IDLE);
   DCHECK(state_machine_.HasInitializedOutputSurface());
+  DCHECK(begin_impl_frame_deadline_task_.IsCancelled());
 
   advance_commit_state_task_.Cancel();
 
@@ -534,15 +576,19 @@ void Scheduler::BeginImplFrame(const BeginFrameArgs& args) {
   ProcessScheduledActions();
 
   state_machine_.OnBeginImplFrameDeadlinePending();
-  ScheduleBeginImplFrameDeadline(
-      AdjustedBeginImplFrameDeadline(args, draw_duration_estimate));
+
+  if (ShouldPostBeginImplFrameDeadline()) {
+    ScheduleBeginImplFrameDeadline(
+        AdjustedBeginImplFrameDeadline(args, draw_duration_estimate));
+  } else {
+    OnBeginImplFrameDeadline();

[brianderson, 2014/09/12 22:05:27]

After thinking about this some more, I am a bit concerned with what will happen
if every call to BeginImplFrame takes more than one BeginFrame period.

Once we move Windows over to the unified BeginFrame message, many BeginFrame
messages could pile up onto our message queue.

To avoid pile ups, we need to skip some BeginFrames, which we currently only do
if they are converted into BeginRetroFrames. Calling the deadline synchronously
here will prevent any BeginRetroFrames from being created though.

I wonder if we should just post an immediate task for the deadline instead to
give any pending BeginFrames on the message queue a chance to execute before the
deadline tasks is run (since the deadline task should get queued behind the
BeginFrames).

[sunnyps, 2014/09/15 21:52:48]

An immediate task will also take 15 ms before it executes, right? My
understanding is that immediate tasks happen on the next iteration of the
MessageLoop which should be tied to the system timer resolution.

[sunnyps, 2014/09/16 21:30:31]

I've gone through some of the MessageLoop/MessagePump source code and I think
what you're saying is correct. We can post a deadline task with delay 0 and that
should run immediately (after the current run loop iteration).

I'm also wondering if the scheduler state machine should know about any of this.

+  }
 }
 
 base::TimeTicks Scheduler::AdjustedBeginImplFrameDeadline(
     const BeginFrameArgs& args,
     base::TimeDelta draw_duration_estimate) const {
-  if (settings_.using_synchronous_renderer_compositor) {
-    // The synchronous compositor needs to draw right away.
+  if (!ShouldPostBeginImplFrameDeadline()) {
     return base::TimeTicks();
   } else if (state_machine_.ShouldTriggerBeginImplFrameDeadlineEarly()) {
     // We are ready to draw a new active tree immediately.
@@ -566,15 +612,6 @@ base::TimeTicks Scheduler::AdjustedBeginImplFrameDeadline(
 void Scheduler::ScheduleBeginImplFrameDeadline(base::TimeTicks deadline) {
   TRACE_EVENT1(
       "cc", "Scheduler::ScheduleBeginImplFrameDeadline", "deadline", deadline);
-  if (settings_.using_synchronous_renderer_compositor) {
-    // The synchronous renderer compositor has to make its GL calls
-    // within this call.
-    // TODO(brianderson): Have the OutputSurface initiate the deadline tasks
-    // so the sychronous renderer compositor can take advantage of splitting
-    // up the BeginImplFrame and deadline as well.
-    OnBeginImplFrameDeadline();
-    return;
-  }
   begin_impl_frame_deadline_task_.Cancel();
   begin_impl_frame_deadline_task_.Reset(begin_impl_frame_deadline_closure_);