Re: requestAnimationFrame

On 11/15/10 6:03 PM, Gregg Tavares (wrk) wrote:
> One is, how should this api be used if I want an app to update at 10hz.
>   It seems to be designed to assume I want the maximum frame rate.

The initial API was designed to replace setTimeout(..., 0) animations, 
yeah.  The idea was to ask for "animate as smoothly as possible" but 
allow the browser to choose the actual animation rate.

> setInterval(function() {
>     window.requestAnimationFrame();
>    }, 100); // request frames at 10hz?

This seems like it would work, yes.... It may be suboptimal if you have 
multiple consumers, because you end up with multiple timers in flight. 
But you'd get that anyway if you had some consumers wanting 10Hz and 
some wanting 11Hz and some wanting 9Hz....

It's worth thinking about this a bit, but I'm not sure there's a great 
solution here.

> But that brings up the next question. I'm in some alternate world where
> there is no Flash, instead all ads are implemented in Canvas. Therefore
> a site like cnn.com <http://cnn.com> or msnbc.com <http://msnbc.com> has
> 5 canvases running ads in each one.  I don't really want all 5 canvases
> redrawn if they are not on the screen but the current design has
> requestAnimationFrame and beforePaint to be window level apis.

Note that the beforePaint event can make arbitrary changes to the DOM 
(and in particular can change whether things are visible)...

> 1) All of them will get a beforePaint event even if most or all of them
> are scrolled off the visible area since there is only 1 beforePaint
> event attached to the window.
>
> 2) All of them will get beforePaint events at the speed of the fastest
> one. If one ad only needs to update at 5hz and other updates at 60hz
> both will update at 60hz.
>
> Do those issues matter? If they do matter would making both
> requestAnimationFrame and beforePaint be element level APIs solve it?

The current mozRequestAnimationFrame implementation allows passing a 
function.  If no function is passed, an event is fired at the window. 
If a function is passed, that function is called.  So in this case, each 
canvas could pass a separate function that just modifies that canvas. 
If they want to throttle themselves they'd use your setInterval 
suggestion above as needed.  That would address #2 above.  I suppose we 
could do something similar with events and event handlers if people 
think it's a better API.

For #1, things are more difficult; a lot of the work you have to do to 
determine whether something is inside the visible area is work you want 
to put off until _after_ all the beforePaint handlers have run.

-Boris

Received on Monday, 15 November 2010 23:29:14 UTC