[whatwg] A better animation API
ian at hixie.ch
Tue Jan 31 15:12:23 PST 2012
On Sat, 10 Dec 2011, Robert Eisele wrote:
> mozRequestAnimationFrame became part of Firefox 4 Beta 4 and as a result
> also (o|webkit|ms)RequestAnimationFrame got implemented. This way
> animations can be slow downed safely to a minimum when the animation is
> executed in an inactive tab or something like that. Also the performance
> and the synchronicity with CSS keyframes can be improved directly inside
> the browser. [...]
> All that's nice, but why is there no general proposal implementing a
> native setInterval replacement? Also Robert O'Callhan mentioned a
> http://robert.ocallahan.org/2010/08/mozrequestanimationframe_14.html .
> Sure, it's more dangerous but also setInterval has this kind of hazard.
> It's certainly also more difficult to implement but asking for every
> frame to continue has also the disadvantage of beeing as slow as setting
> up a new timeout for every frame. That's why setInterval surpass
> setTimeout's performance (okay, at least it should).
> Maybe an API would also make sense, which runs for a given duration.
> This way, animations like jQuery's animate() could profit immensely from
> a native API. [...]
On Mon, 12 Dec 2011, Nicholas C. Zakas wrote:
> I'd like to +1 the suggestion for a continuous animation loop, though if
> I remember correctly I think the concern about such an API was that it
> would lead to forgotten animations that would keep going long past they
> I'd much rather have an API to start and stop animations, but I'm not
> sure if the developer convenience outweighs the potential downside of
> forgotten, long-running paint requests.
I recommend approaching the Web Performance working group who are working
on the animation API:
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg