Defer starting of animations until after compositing update

Source/core/animation/AnimationClock.h

 /*
  * Copyright (C) 2013 Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
  *     * Redistributions in binary form must reproduce the above
@@ skipping 18 matching lines @@
  */
 
 #ifndef AnimationClock_h
 #define AnimationClock_h
 
 #include "wtf/CurrentTime.h"
 #include "wtf/PassOwnPtr.h"
 
 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)
     {
         return adoptPtr(new AnimationClock(monotonicallyIncreasingTime));
     }
 
     void updateTime(double time)
     {
         if (time > m_time)
             m_time = time;
         m_frozen = true;
     }
 
     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;
     }
 
     void unfreeze() { m_frozen = false; }
 
     void resetTimeForTesting() { m_time = 0; m_frozen = true; }
 
 private:
     AnimationClock(WTF::TimeFunction monotonicallyIncreasingTime)
         : m_monotonicallyIncreasingTime(monotonicallyIncreasingTime)
         , m_time(0)
         , m_frozen(false)
     {
     }
     WTF::TimeFunction m_monotonicallyIncreasingTime;
     double m_time;
     bool m_frozen;
 };
 
 } // namespace WebCore
 
 #endif // AnimationClock_h