cc: Move scheduling logic out of OutputSurface

cc/scheduler/scheduler_state_machine.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_state_machine.h"
 
 #include "base/debug/trace_event.h"
 #include "base/format_macros.h"
 #include "base/logging.h"
 #include "base/strings/stringprintf.h"
@@ skipping 785 matching lines @@
     return !BeginFrameNeededToDraw() && ProactiveBeginFrameWanted();
   }
 
   // Non synchronous compositors should rely on
   // ProactiveBeginFrameWanted to poll for state instead.
   return false;
 }
 
 bool SchedulerStateMachine::SupportsProactiveBeginFrame() const {
   // Both the synchronous compositor and disabled vsync settings
-  // make it undesirable to proactively request BeginImplFrames.
+  // make it undesirable to proactively request BeginFrames.
   // If this is true, the scheduler should poll.
   return !settings_.using_synchronous_renderer_compositor;

[Sami, 2014/04/22 18:34:13]

Should we also check throttle_frame_production here or is the comment out of
date?

[brianderson, 2014/04/22 22:34:49]

I will update the comment. The way disabled vsync works now, we will not busy
loop like we used to.

 }
 
 // These are the cases where we definitely (or almost definitely) have a
 // new frame to draw and can draw.
 bool SchedulerStateMachine::BeginFrameNeededToDraw() const {
   // The output surface is the provider of BeginImplFrames, so we are not going
   // to get them even if we ask for them.
   if (!HasInitializedOutputSurface())
     return false;
 
@@ skipping 365 matching lines @@
     case OUTPUT_SURFACE_ACTIVE:
     case OUTPUT_SURFACE_WAITING_FOR_FIRST_COMMIT:
     case OUTPUT_SURFACE_WAITING_FOR_FIRST_ACTIVATION:
       return true;
   }
   NOTREACHED();
   return false;
 }
 
 }  // namespace cc