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
