Re: requestAnimationFrame

On Tue, Nov 16, 2010 at 1:45 PM, Gregg Tavares (wrk) <gman@google.com>wrote:

> On Mon, Nov 15, 2010 at 4:07 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> On Tue, Nov 16, 2010 at 12:55 PM, Gregg Tavares (wrk) <gman@google.com>wrote:
>>
>>> 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.
>>>
>>
>> What happens if one element's event handler makes another element visible,
>> will the second element's timer be able to fire or not?
>>
>
> Does it matter?
>

Yes, I think it probably does matter for interop.

What happens now?
>

With mozRequestAnimationFrame, visibility is not relevant to whether the
callbacks fire, so the question does not arise.


> Now, with setInterval there is no connection to rendering. I set the code
> to update one element to have an interval of 16 and another to have an
> interval of 100. If the first one makes the second one visible that doesn't
> effect whether or not the second one's set interval function gets called. If
> there was a setIntervalIfVisible and that behavior was browser independent
> how would that make things worse than they are today? It seem like "if
> visible" is just a hint to the browser that it doesn't need to call the
> interval function if it doesn't want to. It doesn't need to be a guaranteed
> that it will be called when visible any more than the current setInterval is
> a guarantee that it will be called at the interval rate.
>

mozRequestAnimationFrame actually guarantees that you will be called when
the browser paints. Otherwise we can't guarantee that JS animations will
stay in sync with declarative animations.

Now, when animation is happening on a separate compositor thread that
guarantee has to be relaxed a bit. But we'll still try to meet it on a
best-effort basis --- i.e. "we'll run the JS animations once per composited
frame, if the JS can keep up".


>
>> When an element becomes visible, does its timer fire immediately if the
>> last firing was more than 'interval' ago?
>>
>
> Yes? No? Does it matter? What happens now?
>

I suspect it would matter for interop, yes. Again, with
requestAnimationFrame the question does not arise.

I'm not trying to be argumentative. I'm just not seeing the issue. Certainly
> I'd like various areas to be updated together, or in sync, or when visible
> but that seems like it could be up the UA. If one UA has a simple
> implementation and another UA as more complex one that gives a better user
> experience then that's reason to switch to that browser.
>

As Boris mentioned, keeping multiple animations (including declarative
animations) in sync was a design goal for requestAnimationFrame.

This seems like you'd just pass in 0 for the interval. The UA can decide
> whether or not to call you as fast as it can or at 60hz or whatever it
> things is appropriate just as it does for setInterval today.
>

OK.

To summarize, I think you have raised two separate feature requests here:
1) Provide an API that lets authors specify a maximum frame rate
2) Provide an API that lets authors avoid getting a callback while a
particular element is invisible

I'm curious about the use-cases that require #1, and given it can be
implemented on top of requestAnimationFrame, the question for any proposal
is whether the extra convenience justifies the surface area. (And note that
even something like setInternvalIfVisible requires some lines of code for
the animation script to figure out which frame it should display.)

I'm not sure how important #2 is. If your callback includes "if
(element.getBoundingClientRect().top > window.innerHeight) return;", I think
you'd be pretty close to the same effect. But if you have a lot of animated
elements, most of which are not visible, I can see that native support could
be helpful.

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]