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

[Pekka Paalanen]

On Sun, 23 Feb 2014 12:55:06 -0600
Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Feb 23, 2014 1:45 AM, "Pekka Paalanen" <ppaalanen at gmail.com> wrote:
> >
> > Hi,
> >
> > thanks for all the comments, it's encouraging to see a concensus
> > emerging. One reply below...
> >
> > On Sat, 22 Feb 2014 07:50:01 -0600
> > Jason Ekstrand <jason at jlekstrand.net> wrote:
> >
> > > On Feb 22, 2014 2:44 AM, "Axel Davy" <axel.davy at ens.fr> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I like very much the rewording proposed by Pekka.
> > > >
> > > > But I dislike your proposition to send frame callbacks right away if
> the
> > > attached buffer has been attached for a long time.
> > > >
> > > > Your argument seems to be that the client may manage to get to the
> next
> > > pageflip if the frame callback is called right away. But with this
> > > argument, I don't see why this behaviour would be only for buffers
> attached
> > > long ago (and then we refresh at a higher frequency than the screen
> refresh)
> > > >
> > > > Moreover we may say we can always get the two behaviours with client
> side
> > > code:
> > > > . If we keep the current behaviour, the client could know it has
> attached
> > > a buffer for a long time (and that the frame callback it had put, was
> > > already called), so if it wants to try to hit next pageflip, it could
> just
> > > commit right away with a new attach
> > >
> > > Yes, this is what they should be doing.  The more I think about the
> frame
> > > callback, the more I think that clients should just put one with every
> new
> > > draw and just track whether that one has been released or not.
> > >
> > > Unfortunately, we have to do something reasonable in the case where the
> > > client requests a frame without drawing.  I don't want to restrict the
> > > server too much on what it does in that case.  It may, for instance, be
> > > running on some sort of refresh-on-demand hardware and have no concept
> of
> > > "next flip".  When the client asks for a frame callback, it is
> effectively
> > > asking when is a good time to repaint.  If now is a good time, the
> server
> > > should be allowed to say so.
> > >
> > > Pekka, one thing I forgot to mention that should probably be added is
> that
> > > we really should guarantee that frame callbacks get fired in the same
> order
> > > they are requested (per surface order, not global order).
> >
> > Ah, ok. That should be easy to implement by just being careful in
> > how the callback lists are managed. Can you elaborate on a use case
> > where this is especially useful?
> >
> > Recall that frame callbacks never get "discarded", except when the
> > surface is destroyed(?). If the update it was part of gets
> > overridden, the callbacks simply move on to the new update that
> > overwrote the old one, which means that several update's worth of
> > callbacks can trigger at the same time. I guess this is somehow
> > behind your proposition?
> 
> Yes, it is. First off,  we may want to use the language "same order as they
> are committed" instead of "same order as they are requested" to make all
> frame callbacks on the same commit the same.
> 
> I looked at the code and it seems that Weston already does this, so it
> shouldn't break anything or take any extra work to implement.  Really, it's
> a nice guarantee for the client that takes basically no work to implement
> in the server.  If a client normally throttles on frame callbacks and then
> has to suddenly repaint or some reason, it may allow it to avoid the extra
> logic for detecting the old frame callback and throwing it out.  I don't
> know how big of a deal that is because they're all timestamped anyway, but
> it's kind of nice.

I always thought that a client context (e.g. the main app, or toolkit,
or some other lib) always just keeps the last frame callback it sent
for a wl_surface, and simply destroys the old one. That's why I asked
if you knew of any use cases, because I can't imagine a case where
you'd want to keep and process more than one callback.

> More importantly, it cleans up some of the edge-cases.  Most of the time,
> it's going to be one frame call back per application component per attach.
> However, this may not always be the case.  In particular, it makes the
> frame+commit case slightly better defined by providing the simple guarantee
> that the callback from the frame+commit will come after the callback from
> the last attach.

"Come one after another" may still mean that both carry the same
timestamp and both go to the client in the same burst. That is the only
case I can see where the ordering might not be the same as the commit
order.

> Maybe that's not a good reason for the aditional server-side requirement,
> but it just seems to clean things up nicely.

You are certainly making a sensible suggestion, and I agree we can make
it explicit in the spec. I'll spin a v3.


Thanks,
pq