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:36:19 -0700
Cc: robert@ocallahan.org, "Ennals, Robert" <robert.ennals@intel.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-id: <E072789B-8337-4929-98F7-27E3248027F7@apple.com>
To: Jonas Sicking <jonas@sicking.cc>

On Oct 20, 2009, at 5:36 PM, Jonas Sicking wrote:

> On Tue, Oct 20, 2009 at 4:44 PM, Robert O'Callahan <robert@ocallahan.org 
> > wrote:
>> On Wed, Oct 21, 2009 at 11:59 AM, Ennals, Robert <robert.ennals@intel.com 
>> >
>> wrote:
>>> Should we also consider the case where a web site wants to keep its
>>> interface up to date with some server state and is using up CPU  
>>> time and
>>> network resource to do so?
>> You could abuse my proposal to do this, by periodically (as  
>> frequently as
>> you run script now) calling requestAnimationFrame and seeing if you  
>> actually
>> get a paint event. Maybe that's not an ideal solution, though.
> Yeah, I think having an API that lets you check if the page is
> visible, as well as an event that lets you know when the visibility
> changes, would be a good idea. That's better than adding *WhenVisible
> APIs, like setTimeoutWhenVisible, EventSourceWhenVisible, etc.

I agree. I like a status flag plus event better than adding  
WhenVisible variants. The Web app can then decide what activity to  
throttle when the page is not visible.

  - Maciej
Received on Wednesday, 21 October 2009 02:36:53 UTC

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