content: Add RendererScheduler.

content/renderer/scheduler/renderer_scheduler.cc

+// Copyright 2014 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 "content/renderer/scheduler/renderer_scheduler.h"
+
+#include "base/bind.h"
+#include "base/message_loop/message_loop_proxy.h"
+#include "cc/output/begin_frame_args.h"
+#include "content/renderer/scheduler/renderer_scheduler_selector.h"
+
+namespace content {
+
+RendererScheduler::RendererScheduler()
+    : renderer_scheduler_selector_(new RendererSchedulerSelector()),
+      task_queue_manager_(kTaskAndControlQueueCount,
+                          base::MessageLoopProxy::current(),
+                          renderer_scheduler_selector_.get()),
+      control_task_runner_(
+        task_queue_manager_.TaskRunnerForQueue(kControlQueue)) {
+  // renderer_scheduler_selector_->SetQueuePriority(
+  //     kControlQueue, RendererSchedulerSelector::kControlPriority);;
+  renderer_scheduler_selector_->DisableQueue(kIdleTaskQueue);
+  task_queue_manager_.SetAutoPump(kIdleTaskQueue, false);
+}
+
+RendererScheduler::~RendererScheduler() {
+}
+
+scoped_refptr<base::SingleThreadTaskRunner>
+RendererScheduler::TaskRunnerForQueue(QueueId queue) {
+  return task_queue_manager_.TaskRunnerForQueue(queue);
+}
+
+void RendererScheduler::WillBeginFrame(const cc::BeginFrameArgs& args) {
+  main_thread_checker_.CalledOnValidThread();
+  EndIdlePeriod();
+  estimated_next_frame_begin_ = args.frame_time + args.interval;
+}
+
+void RendererScheduler::DidCommitFrameToCompositor() {
+  main_thread_checker_.CalledOnValidThread();
+  if (base::TimeTicks::Now() < estimated_next_frame_begin_) {
+    StartIdlePeriod();
+  }
+}
+
+void RendererScheduler::DidReceiveInputEvent() {
+  control_task_runner_->PostTask(

[alexclarke, 2014/10/20 10:10:10]

On one hand I like the idea of posting tasks to avoid locks, but on the other
hand this regresses the usefulness of ShouldYieldForHighPriorityWork which is
suupposed to be able to transition from false -> true mid task.

[rmcilroy, 2014/10/20 11:34:03]

Good point. We could potentially update the current_policy_ atomic word directly
from the input thread and only do the updates of the renderer_scheduler_selector
priorities on the control task, this would enable the transition mid-task, but
would be a bit more complex. WDYT?

[alexclarke, 2014/10/20 12:48:35]

I think it may be necessary to change policy here.  I'd prefer to keep
EnterSchedulerPolicy the only place where current_policy_ is assigned. 
Unfortunately that implies EnterSchedulerPolicy must be thread safe.

[rmcilroy, 2014/10/21 17:21:26]

I've updated this to have a policy_may_need_update_ dirty bit which is set when
the policy should be updated.  SchedulerPolicy() will check for this and
recalculate the policy if it is set.  I removed EnterSchedulerPolicy and
replaced it with UpdatePolicy, which is still only run on the main thread. 
WDYT?

+      FROM_HERE,
+      base::Bind(&RendererScheduler::EnterSchedulerPolicy,
+                 base::Unretained(this),
+                 kCompositorPriorityPolicy));
+}
+
+bool RendererScheduler::ShouldYieldForHighPriorityWork() {
+  return (SchedulerPolicy() == kCompositorPriorityPolicy) &&
+      task_queue_manager_.PollQueue(kCompositorTaskQueue);
+}
+
+base::TimeTicks RendererScheduler::CurrentFrameDeadlineForIdleTasks() const {
+  main_thread_checker_.CalledOnValidThread();
+  return estimated_next_frame_begin_;
+}
+
+RendererScheduler::Policy RendererScheduler::SchedulerPolicy() const {
+  return static_cast<Policy>(base::subtle::Acquire_Load(&current_policy_));
+}
+
+void RendererScheduler::EnterSchedulerPolicy(Policy policy) {
+  main_thread_checker_.CalledOnValidThread();
+  if (SchedulerPolicy() != policy) {

[picksi1, 2014/10/20 11:42:04]

Should we early out if SchedulerPolicy() == policy rather than making the entire
function conditional?

[rmcilroy, 2014/10/21 17:21:26]

Done.

+    switch(policy) {
+      case kCompositorPriorityPolicy:
+        renderer_scheduler_selector_->SetQueuePriority(
+            kCompositorTaskQueue, RendererSchedulerSelector::kHighPriority);
+        control_task_runner_->PostDelayedTask(

[alexclarke, 2014/10/20 12:48:35]

Suppose you keep your finger down longer than
kCompositoryPriorityAfterTouchTime, won't that result in the policy flapping
between normal and compositor priority?

Also what happens if we shut down while this is pending?

[rmcilroy, 2014/10/21 17:21:26]

Yes I guess you would go to normal prio, then immediately hit compositor prio
again when the next InputEvent happened. The new patchset doesn't have this
issue.
All the pending tasks get deleted in ~MessageLoop which calls
DeletePendingTasks() - this should be fine, right?

+            FROM_HERE,
+            base::Bind(&RendererScheduler::EnterSchedulerPolicy,
+                       base::Unretained(this),
+                       kNormalPriorityPolicy),
+            kCompositoryPriorityAfterTouchTime);
+        break;

[picksi1, 2014/10/20 11:42:04]

When we set Scheduler Policy to Compositor Priority don't we need to 'clean' any
existing delayed tasks that drop us back into normal priority?... Or at least a
ref count that tracks how many enters/exits of highpriority mode we've had?

[rmcilroy, 2014/10/21 17:21:26]

The updated patchset changes this around and should hopefully address your
concerns, let me know what you think?

+      case kNormalPriorityPolicy:
+        renderer_scheduler_selector_->SetQueuePriority(
+            kCompositorTaskQueue, RendererSchedulerSelector::kNormalPriority);
+        break;
+    }
+    base::subtle::Release_Store(&current_policy_, policy);
+  }
+}
+
+void RendererScheduler::StartIdlePeriod() {
+  renderer_scheduler_selector_->EnableQueue(
+      kIdleTaskQueue, RendererSchedulerSelector::kBestEffortPriority);
+  task_queue_manager_.PumpQueue(kIdleTaskQueue);

[picksi1, 2014/10/20 11:42:04]

as above, do we need to clean any other 'return to normal priority' tasks from
the delayed task queue? Or is the delayed task queue not going to be processed
in idle mode?

[rmcilroy, 2014/10/21 17:21:26]

There is no delayed task which sets between idle time enabled / disabled.  The
idle time settings are orthogonal to compositor / normal priority policy and can
happen independently from them.

+}
+
+void RendererScheduler::EndIdlePeriod() {
+  renderer_scheduler_selector_->DisableQueue(kIdleTaskQueue);
+}
+
+}  // namespace content