Unified BeginFrame scheduling

cc/scheduler/scheduler_state_machine.cc

Index: cc/scheduler/scheduler_state_machine.cc
diff --git a/cc/scheduler/scheduler_state_machine.cc b/cc/scheduler/scheduler_state_machine.cc
index 723c40c80c276d42ce3d1e2df2c58f51dfad5742..f3336dbac486ea08a3e8465eb9ab215555a2b2c3 100644
--- a/cc/scheduler/scheduler_state_machine.cc
+++ b/cc/scheduler/scheduler_state_machine.cc
@@ -47,7 +47,8 @@ SchedulerStateMachine::SchedulerStateMachine(const SchedulerSettings& settings)
       smoothness_takes_priority_(false),
       skip_next_begin_main_frame_to_reduce_latency_(false),
       skip_begin_main_frame_to_reduce_latency_(false),
-      continuous_painting_(false) {
+      continuous_painting_(false),
+      children_need_begin_frames_(false) {
 }
 
 const char* SchedulerStateMachine::OutputSurfaceStateToString(
@@ -705,9 +706,11 @@ bool SchedulerStateMachine::BeginFrameNeeded() const {
   // To poll for state with the synchronous compositor without having to draw,
   // we rely on ShouldPollForAnticipatedDrawTriggers instead.
   if (!SupportsProactiveBeginFrame())
-    return BeginFrameNeededToAnimateOrDraw();
+    return (BeginFrameNeededToAnimateOrDraw() || BeginFrameNeededToChildren());

[brianderson, 2014/08/28 02:48:07]

This should not include BeginFrameNeededToChildren. In this if block, we should
DCHECK(!BeginFrameNeedeToChildren()) since the synchronous compositor doesn't
have a Browser.

If we ever need to support such a configuration we'd need to figure out a way to
send BeginFrames to children without triggering a Browser draw, which would get
complicated. Luckily, there are no plans to do support that config.

[simonhong, 2014/09/03 21:02:23]

Done.

 
-  return BeginFrameNeededToAnimateOrDraw() || ProactiveBeginFrameWanted();
+  return (BeginFrameNeededToAnimateOrDraw() ||
+          BeginFrameNeededToChildren() ||

[brianderson, 2014/08/28 02:48:07]

BeginFrameNeededToChildren belongs in ProactiveBeginFrameWanted since the
Browser might not draw immediately if the Renderer is slow.

[simonhong, 2014/09/03 21:02:23]

How Browser knows whether Renderer is slow or not in
ProactiveBeginFrameWanted()?
I think it only checks Browser-side scheduler status.

[brianderson, 2014/09/04 18:45:45]

Nevermind about my comment here. What you have is good.

I wanted to think of children wanting BeginFrames as a proactive signal (and
have the logic equal to what you already have), but I think that was just me
trying to fit a new concept into an old way of thinking.

+          ProactiveBeginFrameWanted());
 }
 
 bool SchedulerStateMachine::ShouldPollForAnticipatedDrawTriggers() const {
@@ -733,6 +736,12 @@ bool SchedulerStateMachine::SupportsProactiveBeginFrame() const {
   return !settings_.using_synchronous_renderer_compositor;
 }
 
+void SchedulerStateMachine::SetChildrenNeedBeginFrames(
+    bool children_need_begin_frames) {
+  DCHECK(settings_.begin_frame_publisher && !settings_.begin_frame_receiver);
+  children_need_begin_frames_ = children_need_begin_frames;
+}
+
 // These are the cases where we definitely (or almost definitely) have a
 // new frame to animate and/or draw and can draw.
 bool SchedulerStateMachine::BeginFrameNeededToAnimateOrDraw() const {
@@ -766,6 +775,17 @@ bool SchedulerStateMachine::BeginFrameNeededToAnimateOrDraw() const {
   return needs_redraw_;
 }
 
+bool SchedulerStateMachine::BeginFrameNeededToChildren() const {
+  if (!HasInitializedOutputSurface())
+    return false;
+
+  // If we can't draw, don't tick until we are notified that we can draw again.
+  if (!can_draw_)
+    return false;
+
+  return children_need_begin_frames_;
+}
+
 // These are cases where we are very likely to draw soon, but might not
 // actually have a new frame to draw when we receive the next BeginImplFrame.
 // Proactively requesting the BeginImplFrame helps hide the round trip latency