On 02/22/2014 11:57 PM, Pekka Paalanen wrote:
On Fri, 21 Feb 2014 10:53:03 -0800
Bill Spitzak <spit...@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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
