Bug 238999 – [GTK][WPE] Timestamps delivered to requestAnimationFrame callbacks do not reflect the display refresh that triggered them

• Component: Compositing
• Status: ASSIGNED

[Chris Lord]

I don't know if this is reflected in other backends, but timestamps delivered to rAF callbacks are taken from Performance::now and don't necessarily reflect the display refresh that triggered them. This is noticeable when under load as the timestamps are no longer in line with when the display actually refreshes. This behaviour contradicts both Firefox and Chrome, whose timestamps reflect the cadence at which screen refreshes happen. Practically, this means if you have a 20ms frame time, the distance between rAF timestamps will be ~20ms, even though the actual display will be alternating between 16.7ms and 33.3ms (on a 60Hz refresh).

The spec is pretty loose on what these timestamps need to be, but this difference can have an adverse effect on the fluidity of animations based on rAF timestamps and can also have an effect on synthetic benchmarks.

More information and pictures to follow; I have a patch that fixes this for GTK/WPE (though really only WPE in practice due to an unimplemented feature in the GTK backend)

[Chris Lord]

Created attachment 457063 [details]
Frame times under a 20ms load with Chrome

This data captured with a custom tool shows Chrome's behaviour when continuously drawing frames with a ~20ms load. The red line represents the time between consecutive rAF callbacks and the blue line represents the time elapsed between calling rAF and receiving a callback.

Note how the red line is ping-ponging between 16.67ms and 33.33ms (more or less), representing the cadence of displayed frames on this 60Hz display.

[Chris Lord]

Created attachment 457064 [details]
Frame times under a 20ms load with Firefox

The same thing with Firefox shows the same behaviour, though Firefox has lower latency (other testing hints that Chrome uses a triple buffering setup, which explains the higher latency and smoother frame cadence).

[Chris Lord]

Created attachment 457065 [details]
Frame times under a 20ms load with WebKit/WPE, pre-patch

This shows the behaviour of WebKit/WPE - frame timestamps are delivered at regular 20ms intervals, which doesn't represent the cadence of frame display (note, this is with the patch from bug 233312 applied).

This difference in behaviour can cause inconsistency in animations, and can also cause differences in synthetic benchmarks that don't take into account that rAF timestamps are not a good way to measure performance.

[Chris Lord]

Created attachment 457067 [details]
Frame times under a 20ms load with WebKit/WPE, post-patch

This shows frame times after the patch (which I've yet to attach as it depends on bug 233312) - putting WebKit/WPE's behaviour in line with Firefox and Chrome.

[Simon Fraser (smfr)]

Following the spec, I would expect the timestamp to be taken from Step 9, "Let now be the current high resolution time. [HRT]":
https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model

[Chris Lord]

(In reply to Simon Fraser (smfr) from comment #5)
> Following the spec, I would expect the timestamp to be taken from Step 9,
> "Let now be the current high resolution time. [HRT]":
> https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-
> model

I agree, but this doesn't match the behaviour of either of the other major browsers and has undesirable consequences (animations looking less consistent if they're based on rAF timestamps and possibly skewed benchmark results).

I think the spec is loose enough for the idea of the 'current' time to be the time of the event that triggered the event loop iteration, perhaps. There is other language in the spec that talks about the user agent being in the best position to determine animation-related parameters, which I think could also apply to this situation (at least, other browsers seem to have interpreted it in this way?)

I've altered my tool to also show the delay between performance.now() called at the start of a callback and the timestamp given to the same callback. These ought to be basically the same under the obvious reading of the spec, but are not and instead match my interpretation in the initial comment.

[Chris Lord]

Created attachment 457804 [details]
Frame times under a 20ms load with Chrome

[Chris Lord]

Created attachment 457805 [details]
Frame times under a 20ms load with Firefox

[Simon Fraser (smfr)]

Could you attach your test page?

[Chris Lord]

Created attachment 457872 [details]
Frame time testing page

[Chris Lord]

Created attachment 459890 [details]
Patch

Attaching this patch for the record - this applies after the patch in bug 233312 and makes sure that the timestamp in rAF callbacks is always aligned to the screen refresh, similar to how it is in Firefox and Chrome.

[Adrian Perez]

Created attachment 465772 [details]
Patch v2

This is Chris' patch updated to build on “main”; I am trying to look
now into this issue and one of the first things I wanted to do was
testing the suggested approach.