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

On Tue, Oct 20, 2009 at 7:13 PM, Ennals, Robert <robert.ennals@intel.com> wrote:
>> On Tuesday, October 20, 2009 at 5:37 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Tue, Oct 20, 2009 at 4:44 PM, Robert O'Callahan
>> <robert@ocallahan.org> wrote:
>> > On Wed, Oct 21, 2009 at 11:59 AM, Ennals, Robert
>> <robert.ennals@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 :-)

Sorry, I think I was unclear.

I still think that requestAnimationFrame is a great feature. It's
useful for many other reasons than as a way to deal with non-visible
pages. The fact that it happens to save cycles for non-visible pages
is just a nice benefit.

It's the other features (visible-only-timeouts, visible-only-network)
that I think would be better addressed using a generic visibility API.

/ Jonas

Received on Wednesday, 21 October 2009 07:45:13 UTC