Best practices for client side buffer management

[Pekka Paalanen]

On Wed, 24 Jun 2020 13:35:12 +0200
Sebastian Wick <sebastian at sebastianwick.net> wrote:

> On 2020-06-24 13:14, Pekka Paalanen wrote:
> > On Wed, 24 Jun 2020 19:17:57 +1000
> > Brad Robinson <brobinson at toptensoftware.com> wrote:
> >   

> >> 1. the compositor doesn't change the contents of the buffer and that 
> >> when
> >> it's returned it's still got the old content.  
> > 
> > With Wayland, wl_surface.attach does not allow the compositor to write
> > into the buffer, it only allows reading. So that is safe, also because
> > the client manages its own buffers (allocate, re-use, destroy).  
> 
> Isn't this a little bit more subtle? In particular if you use OpenGL in
> the compositor to access the image there might be layout transitions
> which change the image in place.
> 
> So while the buffer is owned by the compositor the client must not read
> or write to it and when the ownership is transferred back to the client
> the image might be in another layout.
> 
> Or am I missing something here?

Well, graphics is all about lying after all. If no-one can observe it,
it's cool.

Hardware buffers will be read through the appropriate rendering APIs
anyway, so if there is any tricks going on, the driver will make sure
to maintain the illusion.

It's nothing a toolkit developer needs to be concerned with, and it
definitely does not apply to software rendering.

Besides, if the client re-uses the buffer, there is no public protocol
that would demand updating the metadata about it, so the next time the
compositor imports it, it will use the original DRM modifier etc.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200624/8d1e75fc/attachment.sig>