> On Tuesday, October 20, 2009 at 5:37 PM, Jonas Sicking <jo...@sicking.cc> 
> wrote:
> On Tue, Oct 20, 2009 at 4:44 PM, Robert O'Callahan
> <rob...@ocallahan.org> wrote:
> > On Wed, Oct 21, 2009 at 11:59 AM, Ennals, Robert
> <robert.enn...@intel.com>
> > wrote:
> >>
> >> Should we also consider the case where a web site wants to keep its
> >> interface up to date with some server state and is using up CPU time
> and
> >> network resource to do so?
> >
> > You could abuse my proposal to do this, by periodically (as
> frequently as
> > you run script now) calling requestAnimationFrame and seeing if you
> actually
> > get a paint event. Maybe that's not an ideal solution, though.
> Yeah, I think having an API that lets you check if the page is
> visible, as well as an event that lets you know when the visibility
> changes, would be a good idea. That's better than adding *WhenVisible
> APIs, like setTimeoutWhenVisible, EventSourceWhenVisible, etc.

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.  

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.

I'm sure there are lots of reasons why this wouldn't work, but you get the idea 


Reply via email to