[Webkit-unassigned] [Bug 238999] New: [GTK][WPE] Timestamps delivered to requestAnimationFrame callbacks do not reflect the display refresh that triggered them

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=238999

            Bug ID: 238999
           Summary: [GTK][WPE] Timestamps delivered to
                    requestAnimationFrame callbacks do not reflect the
                    display refresh that triggered them
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Compositing
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: clord at igalia.com
                CC: alex at igalia.com, simon.fraser at apple.com
        Depends on: 233312

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)


Referenced Bugs:

https://bugs.webkit.org/show_bug.cgi?id=233312
[Bug 233312] [WPE] Dispatch display refreshes earlier when skipping frames
-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220408/ff96ac73/attachment.htm>