Timing control for script-based animations LC issues

(as of April 10)

References to DOM and HTML Anne van Kesteren
support an element parameter to requestAnimationFrame() Anne van Kesteren
WindowAnimationTiming Ms2ger
It seems unnecessary to have the WindowAnimationTiming interface;
callback as a function or interface? Ms2ger
the spec currently has

| callback FrameRequestCallback = void (DOMTimeStamp time);

This is inconsistent with the rest of the platform
Semantics of the time argument on rAF's FrameRequestCallback Nat Duca
The current rAF spec defines FrameRequestCallback in the following way:

   callback FrameRequestCallback = void (DOMTimeStamp time);

However, we don't define the semantic meaning of the time argument.
requestAnimationFrame time and DOMHighResTimestamp? Nat Duca
requestAnimationFrame behavior on display:none iframes Nat Duca

Should requestAnimationFrame tick on display:none iframes?

Standardizing animationStartTime Jatinder Mann

Should we standardize window.animationStartTime?

Accuracy of timeouts Ruben Arslan
precise control of the duration of the animation
ally: background animation rate: do not throttle Jonathan Chetwynd

"If the page is not currently visible, animations on that page can be throttled heavily"

There are a range of web applications that the user would not wish or expect to be so effected.

ally: Separate capture & display cycles Jonathan Chetwynd

I propose that RAF should not be throttled to 60fps, and that the display cycle be a separate process.

120Hz monitors Mark Rejhon

We found 4 out of 5 browsers stuck to a requestAnimationFrame() standard successfully animating at 120fps @ 120Hz, with 1 out of 5 browsers divergingfrom a widely-implemented requestAnimationFrame behavior due to an arbitrary hard-coded framerate limiter, found in discoveries during several days of nonstop testing.