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

cc/scheduler/frame_rate_controller.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/frame_rate_controller.h"
 
 #include "base/bind.h"
 #include "base/debug/trace_event.h"
 #include "base/location.h"
 #include "base/logging.h"
 #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 {
 
 class FrameRateControllerTimeSourceAdapter : public TimeSourceClient {
  public:
   static scoped_ptr<FrameRateControllerTimeSourceAdapter> Create(
       FrameRateController* frame_rate_controller) {
     return make_scoped_ptr(
         new FrameRateControllerTimeSourceAdapter(frame_rate_controller));
   }
@@ skipping 65 matching lines @@
   return BeginFrameArgs();
 }
 
 void FrameRateController::SetMaxSwapsPending(int max_swaps_pending) {
   DCHECK_GE(max_swaps_pending, 0);
   max_swaps_pending_ = 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);
 }
 
 void FrameRateController::SetDeadlineAdjustment(base::TimeDelta delta) {
   deadline_adjustment_ = delta;
 }
 
 void FrameRateController::OnTimerTick() {
@@ skipping 49 matching lines @@
   if (is_time_source_throttling_)
     return time_source_->NextTickTime();
 
   return base::TimeTicks();
 }
 
 base::TimeTicks FrameRateController::LastTickTime() {
   if (is_time_source_throttling_)
     return time_source_->LastTickTime();
 
-  return base::TimeTicks::Now();
+  return gfx::FrameTime::Now();
 }
 
 }  // namespace cc