This replaces the DISPATCHED state with new sub-states that are possible
with triple buffering:
DISPATCHED_ONE: Double buffering
DISPATCHED_ONE_AND_SCHEDULED: Scheduled switch to triple buffering
DISPATCHED_ONE_AND_SCHEDULED_NOW: Scheduled switch to triple buffering
DISPATCHED_ONE_AND_SCHEDULED_LATER: Scheduled switch to triple buffering
DISPATCHED_TWO: Triple buffering
Triple buffering is currently disabled until the test cases get updated to
handle it in the next commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
Chronologically they already overlap in time as presentation may
complete in the middle of the dispatch function, otherwise they are
contiguous in time. And most switch statements treated the two states
the same already so they're easy to merge into a single `DISPATCHED`
state.
Having fewer states now will make life easier when we add more states
later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
Although since all SCHEDULED* states basically have the same transitions
it's easier to show them as a single state. The mermaid diagram also won't
render correctly if there is a mix of combined and singular states. We
must use either always combined states or always singular states.
Fixes: 5b214dc2b7 ("clutter/frame-clock: Allow scheduling an update in the future")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
The new CLUTTER_FRAME_CLOCK_STATE_SCHEDULED_NOW state is almost
identical to CLUTTER_FRAME_CLOCK_STATE_SCHEDULED, with one important
difference being that it avoids updates from being repeatedly
rescheduled "now" when multiple calls to
clutter_frame_clock_schedule_update_now() are done before the source
is actually dispatched.
Such repeated calls to schedule an update "now" may actually postpone
the dispatch if the CPU is very busy and the source dispatch is
delayed, defeating the purpose of scheduling a frame "now".
It also allows rescheduling "now" when the frame clock is uninhibited
after being inhibited while an update was scheduled "now". This may
be important in cases where the frame clock is inhibited for very
short periods in which it would otherwise lose the state of being
scheduled "now".
Scenarios such as this would become more common with the introduction
of variable refresh rate since it makes scheduling "now" a commonplace
occurrence.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3561>
