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:30 UTC