Use DwmGetCompositionTimingInfo to get vsync info on Windows

base/time_win.cc

Index: base/time_win.cc
diff --git a/base/time_win.cc b/base/time_win.cc
index 71c914da29dabe75003d9e83172269d3ac72a717..0e1c67ed65143366361d464f1713fa20a2b67415 100644
--- a/base/time_win.cc
+++ b/base/time_win.cc
@@ -371,6 +371,11 @@ class HighResNowSingleton {
     return abs(static_cast<long>((UnreliableNow() - ReliableNow()) - skew_));
   }
 
+  TimeDelta FromQPCValue(LONGLONG qpcValue) {
+    return TimeDelta::FromMicroseconds(
+             static_cast<int64>(qpcValue / ticks_per_microsecond_));

[apatrick_chromium, 2012/07/30 19:43:31]

nit: indent 4 spaces.

+  }
+
  private:
   HighResNowSingleton()
     : ticks_per_microsecond_(0.0),
@@ -389,8 +394,8 @@ class HighResNowSingleton {
     LARGE_INTEGER ticks_per_sec = {0};
     if (!QueryPerformanceFrequency(&ticks_per_sec))
       return;  // Broken, we don't guarantee this function works.
-    ticks_per_microsecond_ = static_cast<float>(ticks_per_sec.QuadPart) /
-      static_cast<float>(Time::kMicrosecondsPerSecond);
+    ticks_per_microsecond_ = static_cast<double>(ticks_per_sec.QuadPart) /
+      static_cast<double>(Time::kMicrosecondsPerSecond);
 
     skew_ = UnreliableNow() - ReliableNow();
   }
@@ -409,7 +414,7 @@ class HighResNowSingleton {
 
   // Cached clock frequency -> microseconds. This assumes that the clock
   // frequency is faster than one microsecond (which is 1MHz, should be OK).
-  float ticks_per_microsecond_;  // 0 indicates QPF failed and we're broken.
+  double ticks_per_microsecond_;  // 0 indicates QPF failed and we're broken.

[brianderson, 2012/07/30 19:38:13]

jar, is changing this to a double ok?

[jar (doing other things), 2012/07/30 21:41:33]

<Doh>.... I hadn't noticed this. <woops!>

Can you motivate why you need this level of precision?

I don't see how this would have a positive impact, but will cause more
processing time.

[brianderson, 2012/07/30 22:37:31]

Dividing a 64-bit integer by the 32-bit float could cause problems.  The 64-bit
integer now.QuadPart will be converted to a 32-bit float for the division.  The
precision of the division will be lower for larger magnitudes of now.QuadPart.

For example, suppose ticks_per_microsecond = 1e3 (~=2^10) => 1GHz.  That's
approximately 10 bits of precision in the divisor.  If now.QuadPart is close to
wrapping around, conversion to a 32bit float lops off more than the bottom 32
bits of precision.  That's at least a 2^(32-10) => 2^22 delta between the
magnitude of the LSB of the numerator and the MSB of the denominator.  Which
means we could only detect deltas of 2^22 microseconds (~4 seconds).

Is there anything wrong with my math?

In reality though, the counter probably always starts at 0 and would take many
many years to reach that point.  Are there any platforms that do not start the
counter at 0?

   int64 skew_;  // Skew between lo-res and hi-res clocks (for debugging).
 
   friend struct DefaultSingletonTraits<HighResNowSingleton>;
@@ -446,6 +451,19 @@ int64 TimeTicks::GetQPCDriftMicroseconds() {
 }
 
 // static
+TimeTicks TimeTicks::FromQPCValue(LONGLONG qpcValue) {
+    return TimeTicks() +

[apatrick_chromium, 2012/07/30 19:43:31]

why not TimeTicks::FromInternalValue()?

[brianderson, 2012/07/30 20:16:39]

Copied this trick from TimeTicks::HighResNow() a few lines up.  I could use
FromInternalValue if I changed HighResNowSingleton::FromQPCValue to be
QPCValueToMicroseconds.  That will be more straightforward.  Will change.

+           HighResNowSingleton::GetInstance()->FromQPCValue(qpcValue);

[apatrick_chromium, 2012/07/30 19:43:31]

nit: indent 4 spaces

+}
+
+// static
 bool TimeTicks::IsHighResClockWorking() {
   return HighResNowSingleton::GetInstance()->IsUsingHighResClock();
 }
+
+// TimeDelta ------------------------------------------------------------------
+
+// static
+TimeDelta TimeDelta::FromQPCValue(LONGLONG qpcValue) {
+    return HighResNowSingleton::GetInstance()->FromQPCValue(qpcValue);
+}