Summary: | [GTK][WPE] Timestamps delivered to requestAnimationFrame callbacks do not reflect the display refresh that triggered them | ||
---|---|---|---|
Product: | WebKit | Reporter: | Chris Lord <clord> |
Component: | Compositing | Assignee: | Chris Lord <clord> |
Status: | ASSIGNED --- | ||
Severity: | Normal | CC: | alex, aperez, bugs-noreply, mcatanzaro, simon.fraser |
Priority: | P2 | ||
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=232918 | ||
Bug Depends on: | 233312 | ||
Bug Blocks: | |||
Attachments: |
Description
Chris Lord
2022-04-08 07:18:30 PDT
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.
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).
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. 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. 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 (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. Created attachment 457804 [details]
Frame times under a 20ms load with Chrome
Created attachment 457805 [details]
Frame times under a 20ms load with Firefox
Could you attach your test page? Created attachment 457872 [details]
Frame time testing page
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. 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.
|