protocol: frame requests run on a schedule

There are applications that expect frame requests to be throttled even
if the surface contents are unchanged. In situations where the
compositor wants the application to make progress, these applications
also expect frame requests to be signaled frequently.

Theses two requirements do not always correspond to any external
schedule imposed on the compositor. For example, consider a compositor
running a single full-screen surface on an output device with an
infinite VRR range. In such a situtation, the compositor has to create
an artificial schedule on which to dispatch frame requests.

Signed-off-by: Julian Orth <ju.orth@gmail.com>
This commit is contained in:
Julian Orth 2024-07-15 10:09:34 +02:00
parent 1554c71793
commit ea47710ac2

View file

@ -1593,6 +1593,11 @@
Clients should therefore only submit a single frame request for a
surface at a time.
Frame requests of a surface should be signaled on a schedule, that is,
when a frame request is signaled, frame requests that are committed
afterwards should not be signaled until some time in the future. The
spacing between these points in time need not be regular.
The object returned by this request will be destroyed by the
compositor after the callback is fired and as such the client must not
attempt to use it after that point.