If a stopped repaint loop gets restarted due to posting of new damage, and this restart of the repaint loop happens late in the video refresh cycle, ie. already inside the repaint-window and thereby after the composition deadline for the current frame, then defer the actual output repaint to the composition deadline of the next video refresh cycle by setting the repaint timer accordingly. This tries to make sure that: a) Client(s) posting damage timely before the composition deadline (video refresh duration - "repaint-window" duration) of the current refresh cycle will trigger a repaint within the current refresh cycle, thereby avoiding one extra frame of compositor lag due to the needed restart of the repaint loop if the loop was stopped. This allows them to benefit from the earlier "instant repaint restart" commit to keep latency low. b) Late clients which post damage close to the end of a refresh cycle can't race other clients if the repaint loop is restarted. Instead they will get deferred to the next compositor cycle, just as if the repaint loop would have been already running - the semantic of the "repaint-window" parameter is preserved. This is especially important to prevent a very late client from triggering a repaint very close to the vblank, which would cause the compositor to certainly miss the vblank and skip one frame and then cause a delay of another frame for other clients which posted their damage in time for the following frame. Iow. this provides clients with a more predictable compositor timing and makes it easier for them to latch onto the compositors repaint cycle. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>dev
parent
f507ec3587
commit
b7df04ebc0
Loading…
Reference in new issue