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

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

From: Ennals, Robert <robert.ennals@intel.com>
Date: Wed, 21 Oct 2009 04:31:32 +0100
To: Brian Kardell <bkardell@gmail.com>
CC: Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, "robert@ocallahan.org" <robert@ocallahan.org>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <EB332302649177439359CE520D92A0AF9F3963AB@irsmsx503.ger.corp.intel.com>
Actually, I think Robert O'Callahan just made me change my mind on this one. The choice of when to consider something "inactive" should probably be left up to the user agent, rather than being part of a specification.

-Rob

> -----Original Message-----
> From: Brian Kardell [mailto:bkardell@gmail.com]
> Sent: Tuesday, October 20, 2009 8:12 PM
> To: Ennals, Robert
> Cc: Maciej Stachowiak; Jonas Sicking; robert@ocallahan.org; public-
> webapps@w3.org
> Subject: Re: solving the CPU usage issue for non-visible pages
> 
> Right... Not to beat the point - but page or window? :)  You said page
> again and I'm just trying to get some clarity...
> 
> 
> On Tue, Oct 20, 2009 at 8:05 PM, Ennals, Robert
> <robert.ennals@intel.com> wrote:
> > [my last attempt at an inline reply seems to have interacted
> strangely with Maciej's email client, so I'm going to top-post for the
> moment until I work out what was going on]
> >
> > Good point. I don't know what other people are thinking, but when I
> say "invisible" I'm thinking about pages that have been minimized or
> are in an invisible tab. Changing the semantics of a page when it is
> occluded by another page could be confusing.
> >
> > -Rob
> >
> >> -----Original Message-----
> >> From: Brian Kardell [mailto:bkardell@gmail.com]
> >> Sent: Tuesday, October 20, 2009 7:58 PM
> >> To: Maciej Stachowiak
> >> Cc: Ennals, Robert; Jonas Sicking; robert@ocallahan.org; public-
> >> webapps@w3.org
> >> Subject: Re: solving the CPU usage issue for non-visible pages
> >>
> >> So... in describing this feature:
> >>
> >> Is it really the visibility of the page that is being queried - or
> the
> >> some kind of state of a window?  Maybe it's a silly bit of
> semantics,
> >> but it seems clearer to me that most of the things discussed here
> are
> >> about a whole window/tab being "minimized" (either to a taskbar or
> tab
> >> or something).  If I have one app open and it is covering a browser
> >> window - the browser window is not visible (it's lower in the
> stacking
> >> order).  Likewise, a page is generally "partially" visible
> >> (scrollbars) so that seems more confusing than it needs to be too.
> >>
> >>
> >> On Tue, Oct 20, 2009 at 7:41 PM, Maciej Stachowiak <mjs@apple.com>
> >> wrote:
> >> >
> >> > 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.
> >> > Regards,
> >> > Maciej
> >> >
> >
Received on Wednesday, 21 October 2009 03:34:11 GMT

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