graphics_metrics_definitions.md 4.2 KB

Graphics metrics: Definitions

We need to have a metric to understand the smoothness of a particular interaction (e.g. scroll, animation, etc.). We also need to understand the latency of such interactions (e.g. touch-on-screen to scroll-displayed-on-screen), and the throughput during the interaction.

[TOC]

We define these metrics as follows:

Responsiveness / Latency

Responsiveness is a measure of how quickly the web-page responds to an event. Latency is defined as the time between when an event happens, (e.g. moving a touch-point on screen) and when the screen is updated directly in response to that event [1]. For example, the event could be a moving touch-point on the touchscreen, and the update would be scrolled content in response to that (may only require the compositor frame update). If a rAF callback was registered, the event would be the one that caused the current script execution (e.g. a click event which triggered rAF), and the update would be the displayed frame after the rAF callback is run and the content from the main-thread has been presented on screen.

Throughput

The ratio between the number of times the screen is updated for a particular interaction (e.g. scroll, animation, etc.), and the number of times the screen was expected to be updated (see examples below). On a 60Hz display, there would ideally be 60 frames produced during a scroll or an animation.

DroppedFrames / SkippedFrames

The ratio between the number of dropped/skipped frames for a particular interaction, and the number of times the screen was expected to be updated. This is the other part data of Throughput so it is a «lower-is-better» metric and works better with current out perf tools.

Smoothness / Jank

Smoothness is a measure of how consistent the throughput is. Jank during an interaction is defined as a change in the throughput for consecutive frames. To explain this further:

Consider the following presented frames:

f1   f2   f3   f4   f5   f6   f7   f8   f9

Each highlighted fn indicates a frame that contained response from the renderer[2]. So in the above example, there were no janks, and throughput was 100%: i.e. all the presented frames included updated content.

Considering the following frames:

f1   f2   f3   f4   f5   f6   f7   f8   f9

In this case, frames f3 and f5 did not include any updates (either display-compositor was unable to submit a new frame, or the frame submitted by the display compositor did not include any updates from the renderer). Therefore, the throughput during this interaction is 78%.

To explain the jank, during the first two frames [f1, f2], the throughput is 100%. Because of the subsequently missed frame f3, the throughput changes for [f2, f4] drops to 67%. The throughput for [f4, f6] is also 67%. For subsequent frames, the throughput goes back up to 100%. Therefore, there was a single jank.

Consider the following two sequences:

f1   f2   f3   f4   f5   f6   f7   f8   f9

f1   f2   f3   f4   f5   f6   f7   f8   f9

In both cases, throughput is 55%, since only 5 out of 9 frames are displayed. In the first sequence, there is a jank ([f1, f2][f2, f3][f3, f4] has 100% throughput, but [f4, f9] has a throughput of 33%). However, in the second sequence, there are no janks, since [f1, f3] [f3, f5] [f5, f7] [f7, f9] all have 67% throughput.

[1]: Indirect updates in response to an event, e.g. an update from a setTimeout() callback from an event-handler would not be associated with that event.

[2]: Note that the response could be either an update to the content, or a notification that no update is expected for that frame. For example, for a 30fps animation in this frame-sequence, only frames f1 f3 f5 f7 f9 will have actual updates from the animation, and frames f2 f4 f6 f8 should still have notification from the client that no update is expected.