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

Re: solving the CPU usage issue for non-visible pages

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 20 Oct 2009 19:41:16 -0700
Cc: Jonas Sicking <jonas@sicking.cc>, "robert@ocallahan.org" <robert@ocallahan.org>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-id: <511C9508-ACD2-4D03-B940-FD4836BF4A93@apple.com>
To: "Ennals, Robert" <robert.ennals@intel.com>

On Oct 20, 2009, at 7:13 PM, Ennals, Robert wrote:

> One thing I like about the "requestAnimationFrame" approach is that  
> it makes it easy to do the right thing. If the simplest approach  
> burns CPU cycles, and programmers have to think a bit harder to  
> avoid doing this, then I suspect the likely outcome would be that  
> many programmers will take the shortest path, and not check whether  
> their page is visible.

It's nice if you are able to re-engineer your animations enough to  
make use of it. The other approaches discussed seem easier to bolt on  
to existing code.

Note: if you really want to optimize CPU use, then the best thing IMO  
is to use CSS Transitions or CSS Animations, that way the browser is  
fully in control of the frame rate and in many cases can do most of  
the work on the GPU, with no need to execute any script as the  
animation goes. I think this has the potential to be more CPU-friendly  
than the requestAnimationFrame approach, though obviously it's not  
applicable in some cases (e.g. canvas drawing).

> I'd even be tempted to risk breaking existing applications a little  
> bit and make the *default* behavior for HTML5 pages be that "time  
> stops" when a page is not visible. If a programmer has a good reason  
> to run javascript on an invisible page then they should have to pass  
> an option to make it clear that they know what they are doing.

One challenge with this approach is that there's no good way at  
present to make time stop for a plugin. I suspect more generally that  
this approach would cause compatibility bugs.

Received on Wednesday, 21 October 2009 02:41:49 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC