I have a proposal for solving this here:

The gist is very simple:
1) window.requestAnimationFrame(): Signals that an animation is in progress,
and requests that the browser schedule a repaint of the window for the next
animation frame, if the window is visible.
2) The browser fires a beforePaint event at the document root element
(bubbling to document and window) any time it repaints the window. This
event contains a 'displayTime' field containing a Javascript Date object
representing the time at which this frame is likely to become visible to the
user. Animation scripts should register an event handler that updates the
DOM/CSS state to show that point in the animation. If the animation has not
ended, the event handler should call window.requestAnimationFrame() again to
ensure another frame will be scheduled in a timely manner.

This gives the browser control over the frame rate, lets it suppress
animation in non-visible windows, lets multiple animations play in
synchrony, and should be easy to retrofit into code that's currently based
on setInterval. I think it can also work well with architectures that do
compositing in a dedicated thread or process.

"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah

Reply via email to