Bug 67873

Summary: Throttle rate of requestAnimationFrame when page is not visible
Product: WebKit Reporter: Chris Marrin <cmarrin>
Component: Layout and RenderingAssignee: Chris Marrin <cmarrin>
Status: RESOLVED FIXED    
Severity: Normal CC: dino, jamesr, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch andersca: review+

Description Chris Marrin 2011-09-09 16:24:11 PDT
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?
Comment 1 James Robinson 2011-09-09 16:31:38 PDT
(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
Comment 2 Chris Marrin 2011-09-09 16:44:53 PDT
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.
Comment 3 Chris Marrin 2011-09-26 15:54:41 PDT
*** Bug 68772 has been marked as a duplicate of this bug. ***
Comment 4 Radar WebKit Bug Importer 2011-09-30 17:32:04 PDT
<rdar://problem/10218835>
Comment 5 Chris Marrin 2011-10-14 17:29:07 PDT
Created attachment 111113 [details]
Patch
Comment 6 James Robinson 2011-10-14 17:33:19 PDT
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.
Comment 7 Chris Marrin 2011-10-17 11:27:22 PDT
(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?
Comment 8 Chris Marrin 2011-10-17 13:14:56 PDT
Committed r97640: <http://trac.webkit.org/changeset/97640>