This is essentially a "soft" requirement for VRR which makes frequent use of
clutter_frame_clock_schedule_update_now()-like scheduling. I have rarely seen this being an issue in practice, but it's possible that I simply haven't created the right conditions to reproduce it. I'm proposing it here for general correctness.
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
Scenarios such as this would become more common with the introduction
of variable refresh rate since it makes scheduling "now" a commonplace