Defer starting of animations until after compositing update

Source/core/animation/AnimationClock.h

Index: Source/core/animation/AnimationClock.h
diff --git a/Source/core/animation/AnimationClock.h b/Source/core/animation/AnimationClock.h
index f6a2cdb84991f6777818a1f67bf251d269e1b757..3b295d770235f57cd6de2170159552d0ba919e78 100644
--- a/Source/core/animation/AnimationClock.h
+++ b/Source/core/animation/AnimationClock.h
@@ -36,6 +36,13 @@
 
 namespace WebCore {
 
+// FIXME: This value is used to suppress updates when time is required outside of a frame.
+// The purpose of allowing the clock to update during such periods is to allow animations
+// to have an appropriate start time and for getComputedStyle to attempt to catch-up to a
+// compositor animation. However a more accurate system might be to attempt to phase-lock
+// with the frame clock.
+const double minTimeBeforeUnsynchronizedAnimationClockTick = 0.005;

[abarth-chromium, 2014/02/24 06:14:08]

Where does this constant come from?  Would this constant be different if we were
running at 120 Hz or 30 Hz?

[dstockwell, 2014/02/24 06:58:07]

I think whatever we choose here is going to be fairly arbitrary. If we knew the
rate as always 120 Hz or 30 Hz I would have chosen a different value. I used 200
Hz as it's greater than the rate for most users and 5ms is still a significant
amount of time.

The cases where this value has an effect are 1. getComputedStyle for compositor
animations and 2. the start times of animations created under the (experimental)
Web Animations API.

For #1, this seems an improvement over the current situation where
getComputedStyle would always advance a compositor animation to the current
time. Now we'll only advance once 5ms have elapsed since the last frame time
reported to the main thread. (we could improve here by forwarding frame times
even when not animating on the main thread, but I don't actually think this is a
very important use case).

For #2, it means two players created 5ms apart (outside a RAF callback) will not
have the same start times. The exact mechanism here is still pending some
discussion in the spec group, eg. the clock might remain frozen until the script
callback finishes.

+
 class AnimationClock {
 public:
     static PassOwnPtr<AnimationClock> create(WTF::TimeFunction monotonicallyIncreasingTime = WTF::monotonicallyIncreasingTime)
@@ -52,8 +59,11 @@ public:
 
     double currentTime()

[abarth-chromium, 2014/02/24 06:14:08]

Should we move these functions out of line now that they're non-trivial?

[dstockwell, 2014/02/24 12:41:16]

Done.

     {
-        if (!m_frozen)
-            updateTime(m_monotonicallyIncreasingTime());
+        if (!m_frozen) {
+            double newTime = m_monotonicallyIncreasingTime();
+            if (newTime >= m_time + minTimeBeforeUnsynchronizedAnimationClockTick)
+                m_time = newTime;
+        }
         return m_time;
     }