W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: requestAnimationFrame

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 15 Nov 2010 21:17:50 -0500
Message-ID: <4CE1E9CE.7000907@mit.edu>
To: "Gregg Tavares (wrk)" <gman@google.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
On 11/15/10 6:55 PM, Gregg Tavares (wrk) wrote:
> How would setInterval with multiple functions on
> mozRequestAnimationFrame solve this issue? They are still all going to
> get called at the fastest interval right?

Why?

setInterval(function() {
   window.requestAnimationFrame(function redrawElem1() { /* ... */ });
}, 33);
setInterval(function() {
   window.requestAnimationFrame(function redrawElem2() { /* ... */ });
}, 100);

This should redraw elem1 close to 30Hz and elem2 close to 10Hz.

> Or did you mean if mozRequestAnimationFrame was moved to an element level function?

The element involved can be encoded in the callback function passed to 
requestAnimationFrame, as above.

> I've seen proposals for something more like
>
>        element.setInternvalIfVisible(func, internval);
>
> Which is the same as setInterval but only gets called if the element is
> visible.

Right, but the point is that the work of determining whether things are 
visible is work you want to do _after_ animations have updated...

> With that kind of API there is no connection to rendering.

I'm not sure what that means.

> Would something more like that solve the issue?

Which issue are we trying to solve?

The idea of the current animation frame API was to solve the following 
problems:

1)  Provide a way to create smooth DOM animations that synchronize with
     SMIL and CSS3 Transitions.
2)  Provide a way to throttle all such animations on the UA side (that
     includes throttling SMIL and Transitions).

It sounds like you're trying to solve a somewhat different problem, right?

-Boris
Received on Tuesday, 16 November 2010 02:18:24 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT