I attempt to provide the reasons behind the proposal, and the
necessary context to understand them, in the document. But it may also
be helpful to look at this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=731974 And in particular, the IRC chat log attached to it.
To try and summarize here:
The current requestAnimationFrame API is a good starting point and
works well if your goal is to render smooth animations with no
computational component. Unfortunately, it's a poor fit as a
scheduling tool for games and game-like applications, and it's also
not a great fit for vertically-synced rendering. It also requires
fairly precise timer scheduling in order to produce good results.
My proposed API decouples computation and game logic from rendering,
allows rendering to be dropped in response to CPU load without
dropping logic, allows an app developer to clearly communicate their
scheduling requirements to the browser, and allows the browser to
communicate about the constraints affecting its scheduling so that
each side can adapt. Plus, it would allow an app developer to build a
game that runs smoothly and correctly even in the presence of flaky
timer scheduling (like Firefox has right now) - something I personally
suspect is valuable when talking about running on mobile.
I've attempted to keep the API as simple as possible (with some marked
'nice to have' potential routes for useful expansion) and make it
something that can be implemented as a polyfill on top of
requestAnimationFrame/setTimeout (though a polyfill would not provide
many benefits without access to the control and knowledge available to
a browser author).
If anyone has thoughts, questions, or concerns, please feel free to
share them here on the list, or by contacting me directly. I'd also be
glad to have a discussion on moz irc or google talk.