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

Re: requestAnimationFrame

From: Gregg Tavares (wrk) <gman@google.com>
Date: Tue, 23 Nov 2010 15:08:48 -0800
Message-ID: <AANLkTikDBaW3OT=g71k5Vq7dDxpi_NQRJ1xTB-uw2Jr=@mail.gmail.com>
To: robert@ocallahan.org
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, Ojan Vafai <ojan@chromium.org>, "public-webapps@w3.org" <public-webapps@w3.org>
How about this way of looking at it

Goals

1) prevent programmer error
2) provide a good user experience (browser is responsive with lots of tabs)

The solution to #1 as currently proposed is to guarantee that
requestAnimationFrame will have it's callback called periodically, even if
it's not visible.

What's the solution to #2 in world where requestAnimationFrame is always
called periodically?  One solution was mentioned which is the browser can
freeze the tab. I don't see how guaranteeing calling requestAnimationFrame
once a second or so is compatible with "freeze the tab". Wouldn't that break
the contract?

The problem I'm trying to address is not one of freezing a tab. That has
issues. Sites like gmail, meebo, hotmail, yahoo mail, various twitter sites,
etc all do setInterval or setTimeout processing to get the messages from the
server. That's a reasonable thing to do with setTimeout and setInterval.
Those are generally not very heavy operations. Getting a few k or 100k of
text and processing it.  You can't freeze them without breaking their
functionality.

requestAnimationFrame though is generally designed to be used for updating a
canvas (2d or 3d) which will likely be heavy both in terms of CPU usage
(drawing lots of lines/curves/images into the canvas) and in terms of memory
usage (accessing lots of images).

So, imagine you have a netbook and you've got 10-20 tabs open (less than I
usually have open, YMMV). Imagine all the flash content (ads, video UIs) on
those pages is done with canvas. Imagine there has been enough social
pressure so that sites that used to use setInterval or setTimeout to update
their canvas and therefore bog down the browser have switched to
requestAnimationFrame. Now, given that the there's a promise to call the
callbacks periodically, what would be your solution to fix the issue that
the browser is running really slow since each time a callback comes in, 10s
of megs of images have to get swapped in so they can be drawn into a canvas
and then swapped back out when the next canvas gets it's animationFrame
callback?
Received on Tuesday, 23 November 2010 23:09:22 GMT

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