> 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 :-) -Rob
