WIP: clutter/frame-clock: Allow update dispatch while presentation is pending
Status
TODO:
-
Test Wayland session. -
Test X11 session. -
Pass CI.
This MR was completely rewritten after !1285 (merged), so it's very different from its original version. Here's a branch with the previous version on top of 3.36, which behaves similarly but not exactly the same:
https://gitlab.gnome.org/doraskayo/mutter/-/tree/more-frequent-updates-3-36
Description
From the last commit message:
Instead of inhibiting the frame clock while presentation is pending,
only inhibit the creation of the frame.
In case an update is dispatched while presentation is pending, skip
the frame callback and reschedule another update at the next frame
interval. Timeline updates are considered part of the frame and therefore
skipped as well.
Since updates are still scheduled to occur not more than once in every
refresh period, and only when an update is due, the update frequency
in idle and light rendering workloads remains the same and isn't
affected by this change.
However, in scenarios where the rendering workload is more intense and
Mutter is expected to redraw at a rate which is lower than the maximum
refresh rate, this change guarantees that updates would still occur
at their scheduled time.
The result of this is smooth hardware cursor movement even under load,
and maximum input event latency of a single refresh period between
Mutter and Wayland clients.
This change does not affect the rate of updates in idle and light
rendering workloads, it should provide a good balance between latency
and power usage.
Hardware Cursor Update Frequency
Moving the cursor on a window that performs "heavy" rendering. Note how the position of the cursor is only updated when the composited frame is presented in the "before" case, and how it is updated according to the monitor refresh rate (144Hz, in this case) in the "after" case, regardless of the composited frames.
Before
After
cursor-test-after Note: The monitor was configured to refresh at 144Hz, but this was recorded at 60 FPS so most of the frames are missing from the video. It is smoother in reality.
Input Event Frequency
Moving the cursor on a Wayland client (weston-smoke) that visualizes input event frequency in the same "heavy" rendering scenario. Note how very few events reach the client in the "before" case, and how their frequency is significantly increased based on the monitor refresh rate (144Hz, in this case) in the "after" case.
Before
After
event-test-after Note: The monitor was configured to refresh at 144Hz, but this was recorded at 60 FPS so most of the frames are missing from the video. It is smoother in reality.
Related Issues
Closes: #1255