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 12:21:14 UTC