On Wed, 24 Jun 2020 13:35:12 +0200 Sebastian Wick <sebast...@sebastianwick.net> wrote:
> On 2020-06-24 13:14, Pekka Paalanen wrote: > > On Wed, 24 Jun 2020 19:17:57 +1000 > > Brad Robinson <brobin...@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
pgpQRhEMNoNwN.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
