cc: Use HighResNow as timebase if it is fast and reliable

cc/scheduler/frame_rate_controller.cc

Index: cc/scheduler/frame_rate_controller.cc
diff --git a/cc/scheduler/frame_rate_controller.cc b/cc/scheduler/frame_rate_controller.cc
index 47c27ed3f8e41c42753bab991df299a05330aaa9..ab5af653bd43b33ddbbec6e8c8de1ebb59f79594 100644
--- a/cc/scheduler/frame_rate_controller.cc
+++ b/cc/scheduler/frame_rate_controller.cc
@@ -11,6 +11,7 @@
 #include "base/single_thread_task_runner.h"
 #include "cc/scheduler/delay_based_time_source.h"
 #include "cc/scheduler/time_source.h"
+#include "ui/gfx/frame_time.h"
 
 namespace cc {
 
@@ -96,6 +97,9 @@ void FrameRateController::SetMaxSwapsPending(int max_swaps_pending) {
 
 void FrameRateController::SetTimebaseAndInterval(base::TimeTicks timebase,
                                                  base::TimeDelta interval) {
+  if (!gfx::FrameTime::TimestampsAreHighRes())
+    timebase = base::TimeTicks();

[piman, 2013/10/23 00:03:45]

mmh, aren't we losing functionality here?
Should we make the UpdateVSyncParameter logic use FrameTime too?

[brianderson, 2013/10/23 13:04:43]

The problem is that the DWM API's on Windows only provide the timebase as a QPC
value, which shares the same timebase as HighResNow(). Translating that to the
Now()'s timebase is going to be error prone and jittery.

I've run with a timebase of 0 in the past and it works very well since there is
no jitter. We would run into the issue of drift over long periods of non-stop
swapping, which will cause us to either 1) eventually skip producing a frame 
because we are producing too fast or 2) skip swapping a frame because we are
producing too slowly. I would prefer that infrequent periodic jank to a more
unpredictable jank every frame though.

One thing I could do (that this patch doesn't do yet) is use the timebase when
there is a parent compositor and deadline scheduling is disabled, since we
control the timebase in that case.

[piman, 2013/10/23 23:45:08]

If 0 is ok, then can we make the producer of the timebase make the decision?
Contract is, we only use FrameTime everywhere, it's a lot simpler to reason
about and less error prone.

[brianderson, 2013/10/24 11:26:52]

Sounds good. I will change the patch.

+
   interval_ = interval;
   if (is_time_source_throttling_)
     time_source_->SetTimebaseAndInterval(timebase, interval);
@@ -165,7 +169,7 @@ base::TimeTicks FrameRateController::LastTickTime() {
   if (is_time_source_throttling_)
     return time_source_->LastTickTime();
 
-  return base::TimeTicks::Now();
+  return gfx::FrameTime::Now();
 }
 
 }  // namespace cc