W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: requestAnimationFrame

From: Gregg Tavares (wrk) <gman@google.com>
Date: Thu, 18 Nov 2010 11:21:56 -0800
Message-ID: <AANLkTinKFPmWydt_E9xgtBq_PQKkMWo8i7XTJaGZLFVw@mail.gmail.com>
To: robert@ocallahan.org
Cc: Boris Zbarsky <bzbarsky@mit.edu>, "public-webapps@w3.org" <public-webapps@w3.org>
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.





>
> 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]
>
Received on Thursday, 18 November 2010 19:22:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT