Re: requestAnimationFrame

On Thu, Nov 18, 2010 at 11:21 AM, Gregg Tavares (wrk) <gman@google.com>wrote:

>
>
> On Thu, Nov 18, 2010 at 12:45 AM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> On Thu, Nov 18, 2010 at 4:03 PM, Gregg Tavares (wrk) <gman@google.com>wrote:
>>
>>> On (a)
>>> Take this page (http://boingboing.net) At the time I checked it today
>>> (6:55pm PST) it had 10 instances of flash running. O page load 3 were
>>> animating continuallty, 7 were idle. The 7 idle ones were all video with
>>> custom UIs. Of those 7, 6 of them will animate constantly once the video is
>>> finished advertising other videos to play. That means at any one time, if
>>> this was canvas based, 9 areas will be re-rendered by JavaScript on each
>>> "animationFrame".  It seems like giving the browser more info by tying these
>>> animation frames to specific elements would let the browser not call
>>> animationFrame callbacks unless the element it is tied to is on the screen
>>> and that would be a pretty good thing. If all 10 of those areas were
>>> re-rendering their ads all the time I suspect that page would get pretty
>>> slow, especially on netbooks. As it is, only 1-3 areas are ever visible at
>>> once.
>>>
>>
>> Yeah, that makes sense.
>>
>> Then I suggest adding requestAnimationFrame to elements, so you can call
>> "element.requestAnimationFrame(callback)".
>>
>> I think there needs to be a guarantee that the callback is eventually
>> called even if the element never becomes visible. People sometimes want to
>> take action when an animation finishes. window.mozRequestAnimationFrame
>> fires once per second even for hidden tabs for this reason.
>
>
> I see your point but I'm a little worried about adding that exception. Take
> the boingboing.net example again. There are 10 areas, 1 is on the screen,
> it's playing video. If once a second all 9 areas have their animationFrame
> callback called that video will probably glitch or stutter once a second.  I
> suppose the UA can stagger the offscreen animationFrame calls but I just
> wonder if calling them at all when they are offscreen is really warranted.
> Or how about I've got boingboing.net in one tab (10 areas), techcrunch.comin another (4 areas),
> geekologie.com in a 3rd (7 areas), nytimes.com in a 4th (3 areas), add a
> few more and soon my machine will end up being bogged down making
> animationFrame callbacks to offscreen tabs.  Is the solution to just keep
> calling each one less and less frequently? I'd prefer it if my under powered
> netbook wasn't spending it's time and battery rendering things offscreen
> ever if possible. Not only that, but as I add more and more tabs I'd like to
> be able to swap them out of memory, but if every second or 2 seconds or 10
> seconds each one gets an animationFrame callback then it will be swapped
> back into memory.
>
>
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.

-Darin



>
>
>
>
>>
>> It's a little tricky to define exactly what it means for an element to be
>> visible. I think we could probably leave that up to the UA without hurting
>> interop.
>>
>>
>> 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]
>>
>
>