Intent to Implement: Frame Timing API

157 views
Skip to first unread message

Paul Irish

unread,
Dec 19, 2014, 2:28:52 PM12/19/14
to blink-dev

Primary eng emails

m...@google.com, vmp...@chromium.org, nd...@chromium.org


Spec

w3c.github.io/frame-timing/


Summary

This specification defines an interface to help web developers measure the rendering performance of their applications in the wild. The API provides frame performance data, as experienced by the end user on their device, to facilitate smoothness measurements (i.e. Frames per Second and Time to Frame). This is done by capturing events for main frame and impl (compositor) thread actions, and exposing them to JavaScript via the Performance Timeline.


Motivation

Motivation is dealt with in more depth at: github.com/w3c/frame-timing/wiki/Explainer

Currently, the only way to get information like this is to call requestAnimationFrame in a tight loop, and count how often you get callbacks. This increases load on the system unnecessarily, and is not entirely accurate.


Compatibility Risk

Low. We’re still iterating on the fine points of the spec language and shape of the API (see open issues at: github.com/w3c/frame-timing/issues), and the intent to implement is to help us inform these decisions through hands-on implementation experience. The feedback from Mozilla and IE teams has been positive so far -- no blocking issues that we’re aware of.


Ongoing technical constraints

None.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


OWP launch tracking bug?

crbug.com/120796 follows development
crbug.com/444122 will track shipping


Link to entry on the feature dashboard

chromestatus.com/features/5558926443544576


Requesting approval to ship?

No.





.

Alex Russell

unread,
Dec 19, 2014, 3:25:40 PM12/19/14
to Paul Irish, blink-dev
I'm incredibly excited to see this moving forward.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Rick Byers

unread,
Dec 19, 2014, 4:35:29 PM12/19/14
to Alex Russell, Paul Irish, blink-dev
+1.  I'm particularly hopeful that this will enable a new class of benchmarks that will make it easier for browsers to compete on directly relevant smoothness goals.

Philip Jägenstedt

unread,
Dec 20, 2014, 7:33:34 PM12/20/14
to Paul Irish, blink-dev
LGTM, this fits perfectly with the overall Blink goals presented at BlinkOn 3.

Key quote from https://github.com/w3c/frame-timing/wiki/Explainer:
"Because of these subtleties, the browser will never have enough information about your app to make intelligent decisions as to what any given visual change implies, nor how it should be meaningfully measured. Instead, the Frame Timing API gives you the raw data you need to build a custom picture of your app’s performance characteristics during periods of interest, like transitions or interactions."

Philip

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Chris Harrelson

unread,
Dec 22, 2014, 1:00:50 PM12/22/14
to Philip Jägenstedt, Paul Irish, blink-dev
LGTM

Glad to see this moving forward also. 

Philip Rogers

unread,
Jan 5, 2015, 6:49:36 PM1/5/15
to Philip Jägenstedt, Paul Irish, blink-dev
+100! This API is clearly useful for Chrome users looking for better data.

Historically, all engines have gamed benchmarks, even when it hurts their users. I'm not sure we will be able to get to a point where cross-engine measurements are possible, but I hope we can. This API is useful even if we don't quite reach that goal though.

On Sat, Dec 20, 2014 at 4:33 PM, Philip Jägenstedt <phi...@opera.com> wrote:
Reply all
Reply to author
Forward
0 new messages