Allow creating a queue of future times to tick at. This adds a new clock
state where we let the clock go idle, but will wake at a time in the
future to tick.
We can still schedule ticks while in this new state, but we're assured a
tick at or shortly after the scheduled time.
This will be used later by wayland code that schedules future presentation.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3355>
A new variable scheduling mode is introduced which allows lower
priority updates to be scheduled on a timeout which represents a lower
refresh rate, while allowing high priority updates to be scheduled to
occur as soon as possible.
This mode will be used by following commits to implement
synchronization of page flips to the update rate of specifc surface
actors.
High priorty updates are either scheduled to occur "now" if they
arrive at a rate which is lower than the maximum refresh rate, or
according to the measured maximum render time if they arrive at a
rate which meets or exceeds the maximum refresh rate. This approach
allows achieving low input latency in both scenarios.
Seperate handling for low priority updates is needed to avoid visible
stutter in the content of the surface that drives the refresh rate. An
example for a low priority update is cursor movement when the KMS
deadline timer is disabled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154>
Not sure how to update the damage or redraw clip or something; at least
this works properly when under a constantly-redrawing window, which is
ok for debugging purposes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
In constrast to notify_presented(), notify_ready() also returns the
state machine to the idle state, but without providing new frame
information, as no frame was actually presented.
This will happen for example with the simple KMS impl backend will do a
cursor movement, which will trigger a symbolic "page flip" reply in
order to emulate atomic KMS behavior. When this happen, we should just
try to reschedule again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
The frame clock owner should be able to explicitly destroy (i.e. make
defunct) a frame clock, e.g. when a stage view is destructed. This is so
that other objects can keep reference to its without it being left
around even after stopped being usable.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Add API to add and remove ClutterTimeline objects to the frame clock.
Just as the legacy master clock, having a timeline added to the frame
clock causes the frame clock to continuously reschedule updates until
the timeline is removed.
ClutterTimeline is adapted to be able to be driven by a
ClutterFrameClock. This is done by adding a 'frame-clock' property, and
if set, the timeline will add and remove itself to the frame clock
instead of the master clock.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The timestamp comes from the GSource, meaning it's a more accurate
representation of when the frame started to be dispatched compared to
getting the current time in any callback.
Currently unused.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
This adds a current unused, apart from tests, frame clock. It just
reschedules given a refresh rate, based on presentation time feedback.
The aiming for it is to be used with a single frame listener (stage
views) that will notify when a frame is presented. It does not aim to
handle multiple frame listeners, instead, it's assumed that different
frame listeners will use their own frame clocks.
Also add a test that verifies that the basic functionality works.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
