(as of April 10)
It seems unnecessary to have the WindowAnimationTiming interface;
the spec currently has | callback FrameRequestCallback = void (DOMTimeStamp time); This is inconsistent with the rest of the platform
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.
Should requestAnimationFrame tick on display:none iframes?
Should we standardize window.animationStartTime?
precise control of the duration of the animation
"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.
I propose that RAF should not be throttled to 60fps, and that the display cycle be a separate process.
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.