[PATCH wayland v2] protocol: try to clarify frame callback semantics

[Pekka Paalanen]

On Fri, 21 Feb 2014 10:53:03 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> 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.

Except that getting a frame callback cannot guarantee visibility,
so this does not quite fit. We want to be able to keep them flowing
even if the surface is temporarily hidden, maybe at a reduced rate,
so that on expose the content would be somewhat up to date.

> "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."

I'm not sure about that. The client should still honour the frame
callbacks, even if it is repainting only based on input events, or
it will risk drawing too often.

> 
> 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.

They are already associated with the update (i.e. commit).


Thanks,
pq

PS. Please, use reply-to-all when replying.