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

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

From: Brian Kardell <bkardell@gmail.com>
Date: Tue, 20 Oct 2009 20:11:47 -0700
Message-ID: <8fcaeb2c0910202011v5dd959cq34511f3c0b0bc18a@mail.gmail.com>
To: "Ennals, Robert" <robert.ennals@intel.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>
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 12:21:14 UTC

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