Use estimated vsync period on Android

ui/android/java/src/org/chromium/ui/VSyncMonitor.java

Index: ui/android/java/src/org/chromium/ui/VSyncMonitor.java
diff --git a/ui/android/java/src/org/chromium/ui/VSyncMonitor.java b/ui/android/java/src/org/chromium/ui/VSyncMonitor.java
index af8f87b5ffd898c832a1fa2f0db7cd590e50ca89..a99fe3d2f9928921858c0e2c7cf0bed83cccb691 100644
--- a/ui/android/java/src/org/chromium/ui/VSyncMonitor.java
+++ b/ui/android/java/src/org/chromium/ui/VSyncMonitor.java
@@ -24,7 +24,10 @@ public class VSyncMonitor {
     private static final long NANOSECONDS_PER_MILLISECOND = 1000000;
     private static final long NANOSECONDS_PER_MICROSECOND = 1000;
 
+    private static final long MAX_VALID_VSYNC_PERIOD_NANOSECONDS = NANOSECONDS_PER_SECOND / 30;
+
     private boolean mInsideVSync = false;
+    private boolean mConsecutiveVSync = false;

[no sievers, 2014/10/03 18:14:54]

nit: Can you put a comment that this is a conservative guess? Since it relies on
us requesting the next tick from inside the callback, which is currently the
case (but there is maybe no good reason to rely on that - it's fine for now I'd
guess we'd have to make it more complicated to detect it otherwise... such as
always requesting an extra tick internally, without necessarily forwarding it to
the requester, before we go idle).

 
     /**
      * VSync listener class
@@ -41,7 +44,7 @@ public class VSyncMonitor {
     private Listener mListener;
 
     // Display refresh rate as reported by the system.
-    private final long mRefreshPeriodNano;
+    private long mRefreshPeriodNano;
 
     private boolean mHaveRequestInFlight;
 
@@ -85,10 +88,21 @@ public class VSyncMonitor {
         if (enableJBVSync && Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN) {
             // Use Choreographer on JB+ to get notified of vsync.
             mChoreographer = Choreographer.getInstance();
+            final boolean useEstimatedRefreshPeriod =
+                    mRefreshPeriodNano > MAX_VALID_VSYNC_PERIOD_NANOSECONDS;
             mVSyncFrameCallback = new Choreographer.FrameCallback() {
                 @Override
                 public void doFrame(long frameTimeNanos) {
                     TraceEvent.begin("VSync");
+                    if (useEstimatedRefreshPeriod && mConsecutiveVSync) {
+                        // Display.getRefreshRate() is unreliable on some platforms.
+                        // Adjust refresh period- initial value is based on Display.getRefreshRate()
+                        // after that it asymptotically approaches the real value.
+                        long lastRefreshDurationNano = frameTimeNanos - mGoodStartingPointNano;
+                        float lastRefreshDurationWeight = 0.75f;

[no sievers, 2014/10/03 18:14:54]

Sorry I meant to use the bigger weight for mRefreshPeriodNano so that the values
end up being smoother and don't jump around. I'd maybe even use
lastRefreshDurationWeight = 0.1f. Then the value after 19 samples should match
the simple moving average (lastRefreshDurationWeight = 1 - (2 / (N + 1))) for a
window size of N = 19.

+                        mRefreshPeriodNano += (long) (lastRefreshDurationWeight *
+                                (lastRefreshDurationNano - mRefreshPeriodNano));
+                    }
                     mGoodStartingPointNano = frameTimeNanos;
                     onVSyncCallback(frameTimeNanos, getCurrentNanoTime());
                     TraceEvent.end("VSync");
@@ -186,6 +200,7 @@ public class VSyncMonitor {
         mHaveRequestInFlight = true;
         if (postSyntheticVSync()) return;
         if (isVSyncSignalAvailable()) {
+            mConsecutiveVSync = mInsideVSync;
             mChoreographer.postFrameCallback(mVSyncFrameCallback);
         } else {
             postRunnableCallback();