[PATCH weston] simple-shm: honour wl_buffer.release

[Pekka Paalanen]

On Wed, 21 Nov 2012 11:22:19 -0500
Kristian Høgsberg <hoegsberg at gmail.com> wrote:

> On Wed, Nov 21, 2012 at 09:26:25AM +0200, Pekka Paalanen wrote:
> > On Tue, 20 Nov 2012 10:26:41 -0800
> > Bill Spitzak <spitzak at gmail.com> wrote:
> > 
> > > Pekka Paalanen wrote:
> > > > On Mon, 19 Nov 2012 15:56:23 -0500
> > > > Kristian Høgsberg <hoegsberg at gmail.com> wrote:
> > > > 
> > > >> On Mon, Nov 19, 2012 at 03:29:09PM +0200, Pekka Paalanen wrote:
> > > >>> Change simple-shm to properly process the wl_buffer.release event, and
> > > >>> not reuse a buffer until it is released by the server, as specified in
> > > >>> the protocol.
> > > >>>
> > > >>> In case the server has not released the buffer, but signals that it has
> > > >>> been shown (frame callback), allocate a second buffer. Simple-shm will
> > > >>> now automatically do double-buffering if needed.
> > > >> Looks fine, but simple-shm is less and less simple.
> > > > 
> > > > Yes, I know, but this is really required by the core protocol. Not
> > > > just nice to have, nor optional.
> > > 
> > > It sounds like Wayland clients *must* do double buffering, is this correct?
> > 
> > They should be prepared to allocate a second buffer, if the compositor
> > does not release the first buffer by the time the client needs to draw
> > again.
> > 
> > > I was under the impression that a client could draw over it's buffer at 
> > > any time, with the caveat that what will get composited to the screen 
> > > may be unpredictable.
> > 
> > It can do that, and then it gets what it deserves: unpredictable output.
> > 
> > > Is it now illegal to write to the memory that the compositor is looking 
> > > at? That makes sense but conflicts with the first few pages of the 
> > > wayland documentation.
> > 
> > Well, it is not technically fatal. The spec wording implies that a
> > client may not re-use the buffer's storage until the compositor
> > releases it. If a client chooses to do it, I'd say it is similar to
> > misusing an API.
> > 
> > We need to fix the docs, then. Where, exactly?
> 
> No, Bill is right, we're not making it illegal or misuse to render
> into a buffer the compositor has locked.  Clients may get transient
> artifacts (tearing, flickering etc), but we're not going to make it
> illegal.  Of course I agree that all real toolkits and all our example
> programs should double buffer.  There is one big use case for
> non-double buffering that we still need to support: xwayland.  In the
> X protocol there is no frame delimiter, nothing that tells you when
> window contents is complete, you just render the command stream as it
> comes in and hope for the best.

We should at least heavily recommend against modifying locked buffers,
if not saying it's illegal or misuse (whatever misuse means here).

It's not like we could actually enforce it in code in any way.


Thanks,
pq