Timing control for script-based animations LC issues

(as of April 10)

References to DOM and HTML Anne van Kesteren

Re: editorial James Robinson (partially accepted)

support an element parameter to requestAnimationFrame() Anne van Kesteren

(Reply) Boris Zbarsky (rejected to a future version)

It seems unnecessary to have the WindowAnimationTiming interface;

+1 Boris Zbarsky
done Cameron McCormack accepted

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.

Re: Semantics of the time argument on rAF's FrameRequestCallback Boris Zbarsky (clarified, no change)
- Re: Semantics of the time argument on rAF's FrameRequestCallback Nat Duca

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?

Re: Standardizing animationStartTime James Robinson (rejected)

Accuracy of timeouts Ruben Arslan

precise control of the duration of the animation

Re: Accuracy of timeouts plh (rejected)

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.

served by setInterval Boris Zbarsky rejected

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.

Not applicable plh rejected

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.