Pipe impl_latency_takes_priority_ to the RenderScheduler.

cc/scheduler/scheduler.cc

Index: cc/scheduler/scheduler.cc
diff --git a/cc/scheduler/scheduler.cc b/cc/scheduler/scheduler.cc
index 0d90c68214f15a822f66419d899885b7a4e84e56..03b9eeca388760153e5fa40cd609f93c8584ae53 100644
--- a/cc/scheduler/scheduler.cc
+++ b/cc/scheduler/scheduler.cc
@@ -354,6 +354,7 @@ bool Scheduler::OnBeginFrameMixInDelegate(const BeginFrameArgs& args) {
   // TODO(brianderson): Adjust deadline in the DisplayScheduler.
   BeginFrameArgs adjusted_args(args);
   adjusted_args.deadline -= EstimatedParentDrawTime();
+  adjusted_args.on_critical_path = !ImplLatencyTakesPriority();

[brianderson, 2015/06/09 01:12:42]

Depending on how the Renderer scheduler uses this flag, you may also want to
make on_critical_path false when MainThreadIsInHighLatencyMode and
!SkipNextBeginMainFrameToReduceLatency since there's no chance of running in
low-latency anyway, but that can come in a followup patch.

[Sami, 2015/06/09 09:47:34]

When this flag is false, the renderer scheduler is going to allow some
non-critical work (e.g., timers) to run with an equal priority to the
BeginFrame. In other words the semantic is that this BeginFrame isn't really
that urgent, so no rush. Do you think the combination high latency and !skip has
that same meaning?

[brianderson, 2015/06/10 01:13:35]

Hmm, probably not. It's more of an in-between priority where the main thread has
a little more time to respond than in low latency mode. A better way to
communicate might be to use a later deadline. Anyways, no need to worry about
this now.

 
   // Deliver BeginFrames to children.
   // TODO(brianderson): Move this responsibility to the DisplayScheduler.