Re: requestAnimationFrame

On Thu, Nov 18, 2010 at 1:54 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Nov 19, 2010 at 10:48 AM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> On Fri, Nov 19, 2010 at 10:46 AM, Darin Fisher <darin@chromium.org>wrote:
>>
>>> I agree.  What's the use case for animating hidden tabs (or canvases that
>>> are hidden)?
>>>
>>> One of the big problems with JavaScript based animations is that they
>>> have no way of knowing they should "go idle" when their window is hidden (in
>>> a background tab or otherwise).  The same API used to rate-limit rendering
>>> could address the problem of hidden tabs too.
>>>
>>
>> Yes. As I mentioned, we do that in Firefox. Please read what I wrote
>> above.
>>
>
> Hmm, maybe I didn't mention it in this thread yet, sorry.
>
> I did mention the reason we want to guarantee the callback eventually
> fires: apps often want to do something when an animation ends. Having to
> write a special code path specifically to handle the case where an animation
> ends but the tab/element is hidden sounds to me like it's going to be
> error-prone.


I totally see that some bad code could be error prone if we don't guarantee
the callback is eventually fired.  On the other hand, guaranteeing it gets
fired even if it's offscreen seems to have all the other repercussions
(excess cpu usage, excess memory paging), those both could lead to a bad
browsing experience.  It seems like guaranteeing animationFrame callbacks
get called even when offscreen is helping bad programmers (their incorrect
code works) where as never calling them when offscreen is helping users
(their browser is more likely to be responsive).  Is there some way to solve
both issues?



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