Re: requestAnimationFrame

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 UTC