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

[Bill Spitzak]

On 02/22/2014 11:57 PM, Pekka Paalanen wrote:
> 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.

So when the compositor knows the surface is hidden, it stops sending the 
frame events? This certainly seems useful and even expected behavior.

You are right that it is impossible to describe the precise behavior in 
a short sentence. I think maybe a short sentence describing the behavior 
in the "typical case" (the surface is on top, visible, has focus, is 
entirely on the primary output, etc). Then it can get into details 
afterwards, and also some of these details probably can vary depending 
on the compositor.

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

You may be right. I was drawing only when idle but this can certainly 
happen more than once per frame. I think this means there is no reason 
for the frame callbacks to be optional, or I may have misread something 
that led me to believe they are optional.

For a typical interactive client, I think the best scheme would be to 
wait until there are no pending events, but only draw if redraw is 
needed and there has been a frame event since the last draw.

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

That's what I thought but some of the discussion about the presentation 
extension was saying that they did not happen unless an attach was done.