[PATCH wayland v2] protocol: try to clarify frame callback semantics
Bill Spitzak
spitzak at gmail.com
Fri Feb 21 10:53:03 PST 2014
How about something like this, which is my understanding:
"The frame callback is sent when it is known that the last commit will
be visible on the screen. If a second commit is sent before the frame
callback it is quite possible the first commit will never be seen, as
the new one will replace it before the output is redrawn.
"A client that is continuously updating the surface should wait for the
frame callback before doing the next drawing and commit. A client that
draws much less often (such as only on user events like mouse move) can
ignore the frame callback and update after user events. A client that
wants more accurate timing by drawing before the frame callback and only
commit afterwards will probably want to use the presentation extension."
PS: I would attach the frame callbacks to commits rather than buffer
attach. I can certainly imagine a client knowing nothing has changed,
and thus not changing the buffers, but still wanting to know when the
next frame callback is given.
More information about the wayland-devel
mailing list