[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