Re: requestAnimationFrame

On Mon, Nov 15, 2010 at 3:28 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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.


How would setInterval with multiple functions on mozRequestAnimationFrame
solve this issue? They are still all going to get called at the fastest
interval right? Or did you mean if mozRequestAnimationFrame was moved to an
element level function?


> 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.
>

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.  With that kind of API there is no connection to rendering. Each
area that needs animation can set the framerate it is hoping to get. The UA
can throttle if it wants to.

Would something more like that solve the issue?



> -Boris
>