cc: Limit ManageTiles calls to once per-frame on average

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 7d8fcd721a32059e07c9167647ea8b22aa7fc167..7763a71f633ffb3adbc21bf7d48156dcf3900e11 100644
--- a/cc/scheduler/scheduler_state_machine.cc
+++ b/cc/scheduler/scheduler_state_machine.cc
@@ -507,9 +507,9 @@ bool SchedulerStateMachine::IsCommitStateWaiting() const {
 
 bool SchedulerStateMachine::ShouldManageTiles() const {
   // ManageTiles only really needs to be called immediately after commit
-  // and then periodically after that.  Limiting to once per frame prevents
+  // and then periodically after that.  Limiting to every other frame prevents

[enne (OOO), 2014/01/15 19:26:44]

Maybe I'm misunderstanding, but I don't think this comment is correct.

If you have a main thread-driven app that's hitting 60hz, then this will prevent
ManageTiles from ever being scheduled because the commit-based one every frame
will keep pushing this number forward.

[brianderson, 2014/01/15 19:39:09]

It's mainly a problem when the main thread is in the "high latency mode". In
that mode, we increment the current_frame_number_, draw a previous commit, and
then start the next commit. In comparison, the draw and commit are swapped in
the low latency mode.

In the low latency mode, what you say is true. We will ManageTiles after the
commit, which will prevent the subsequent draw from triggering a scheduled
ManageTiles.

In the high latency mode, we will run a scheduled ManageTiles after the draw but
can have the commit arrive afterwards, triggering an explicit ManageTiles within
the same frame.

   // post-commit and post-draw ManageTiles on the same frame.
-  if (last_frame_number_manage_tiles_called_ == current_frame_number_)
+  if (last_frame_number_manage_tiles_called_ + 1 >= current_frame_number_)
     return false;
 
   // Limiting to once per-frame is not enough, since we only want to