Bug 67873 – Throttle rate of requestAnimationFrame when page is not visible

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Chris Marrin]

The RequestAnimationFrame spec (http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html) states that non-visible pages should reduce the rate of firing of requestAnimationFrame callbacks when the page is not visible. None of the WebKit implementations of rAF currently do this.

Apparently Firefox throttles to a rate of 0.1Hz. I'm not sure if it's necessary to go that slow. Maybe 1Hz would be sufficient?

[James Robinson]

(In reply to comment #0)
> The RequestAnimationFrame spec (http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html) states that non-visible pages should reduce the rate of firing of requestAnimationFrame callbacks when the page is not visible. None of the WebKit implementations of rAF currently do this.
> 

Chromium does not fire rAF at all when the page is not visible.

> Apparently Firefox throttles to a rate of 0.1Hz. I'm not sure if it's necessary to go that slow. Maybe 1Hz would be sufficient?

Firefox has had an exponential backoff algorithm and a 1Hz delay.  I'm not completely sure what they have now.  Please see:
http://lists.w3.org/Archives/Public/public-web-perf/2011Jul/0039.html

[Chris Marrin]

The question (as brought up in that thread) is whether non-visible pages should be throttled to 0 or some slow rate. As you mention, iOS suspends and that seems to be working fine.

FWIW, you might be able to interpret the spec as saying that events should be fired  no faster than the page renders. When a page is not visible is doesn't render at all, so a frame rate of 0 seems reasonable.

[Chris Marrin]

*** Bug 68772 has been marked as a duplicate of this bug. ***

[Radar WebKit Bug Importer]

<rdar://problem/10218835>

[Chris Marrin]

Created attachment 111113 [details]
Patch

[James Robinson]

Note that this functionality in requestAnimationFrame is defined in terms of the Page Visibility API's DocumentVisibility.hidden attribute (http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PageVisibility/Overview.html#sec-document-visibility-interface), so if you plan to implement that API it might be useful to share plumbing for RAF.  There's an open issue on the page visibility spec about how to deal with a document being visible vs an entire toplevel browsing context (WebCore::Page) but that shouldn't impact the plumbing gunk too much.

[Chris Marrin]

(In reply to comment #6)
> Note that this functionality in requestAnimationFrame is defined in terms of the Page Visibility API's DocumentVisibility.hidden attribute (http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PageVisibility/Overview.html#sec-document-visibility-interface), so if you plan to implement that API it might be useful to share plumbing for RAF.  There's an open issue on the page visibility spec about how to deal with a document being visible vs an entire toplevel browsing context (WebCore::Page) but that shouldn't impact the plumbing gunk too much.

It's nice to see a formal API proposal for this functionality and I think it's right to use it if and when it becomes available. There are several places where we deal with suspend and resume and it's not very consistent. But the time to restructure all this is when that API is implemented. 

I looked and didn't find any WebKit bugs related to this. Do you know of any such bugs?

[Chris Marrin]

Committed r97640: <http://trac.webkit.org/changeset/97640>