[SNIP]
But how does it then help to wait on the CPU instead?A compositor does not "wait" literally. It would only check which state
set is ready to be used, and uses the most recent set that is ready. Any
state sets that are not ready are ignored and reconsidered the next
time the compositor updates the screen.
Depending on which state sets are selected for a screen update, the
global window manager state may be updated accordingly, before the
drawing commands for the composition can be created.
See what I'm proposing is to either render the next state of the windowYes, that's exactly how it would work. It's just that state for a
or compose from the old state (including all atomic properties).
window is not an independent thing, it can affect how unrelated windows
are managed.
A simplified example would be two windows side by side where the
resizing of one causes the other to move. You can't resize the window
or move the other until the buffer with the new size is ready. Until
then the compositor uses the old state.
E.g. what do you do if you timeout and can't have the new window contentAs there is no wait, there is no timeout either.
on time? What's the fallback here?
If the app happens to be frozen (e.g. some weird bug in fence handling
to make it never ready, or maybe it's just bugged itself and never
drawing again), then the app is frozen, and all the rest of the desktop
continues running normally without a glitch.
Thanks,
pq