Review of #1707: a client that draws its next frame only after the
frame callback of the last one sends no new frame while the tick holds
one back, so it got one frame every two refreshes. Once a held frame is
still waiting at the next tick, the tick now draws every frame for a
second before holding one again; such a client loses at most one
refresh per second, while gamescope, which commits without waiting,
keeps drawing on arrival.
The queued draw also checks again that drawing on arrival is still on,
so a frame queued just before streaming, frame generation or paced
output switched on is left for the tick.
On the device, render-on-commit drew only 4-12 % of frames on arrival
while a game ran uncapped: gamescope delivers about one frame per
refresh, so once the tick drew a frame, the next one arrived in the same
refresh, was held back by the once-per-refresh limit and was drawn by
the next tick, which held back the one after it. Waits stayed at ~2 ms.
The tick now leaves a frame younger than one refresh for the next
arrival to draw, unless the tick itself changed the window, effects or
headset pose. A frame no other frame follows is drawn at the tick after.
A new game frame waited for the next screen tick before the compositor
drew it: 1.9-3.5 ms on average at 144 Hz, measured with the pacing
counters. With frames going straight back to the game (no compositor
limit), the compositor now draws as soon as the clients' requests are
handled, at most once per refresh: a second frame in the same refresh
still waits for the tick, and presentation times stay on the tick.
Paced output (glasses), streaming and frame generation keep drawing on
the tick. The hidden pref renderOnCommit (default on) turns it off. The
pacing log line counts the scenes drawn on arrival.
The412Banner