Re: requestAnimationFrame

On Mon, Nov 15, 2010 at 7:24 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

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

So if the JS on the beforePaint takes a while to complete what happens to
the browser? For example if you are resizing the browser? Is the browser
forced not to be able to actually paint until JS returns?


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

So you're saying that there's no guarantee that requestAnimationFrame will
actually keep things in sync?


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