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

[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:06:41 UTC