On Wed, 3 Apr 2019 12:37:56 +1100 Graeme Gill <[email protected]> wrote:
> Pekka Paalanen wrote: > > Hi Pekka, > > > yes, it is not an attribute of wl_surface, but it also is not an > > attribute of a wl_buffer. It is an attribute of the current contents in > > a wl_buffer, contents that will get transferred into the wl_surface on > > commit (by reference or by copy). > > Right, the wl_buffer contains the meta information about the > buffer contents, such as its format, dimensions, layout, etc. > > > In essence, the color space is a > > property of the commit (wl_surface.commit). > > I don't think so. It's a property of the pixel contents. Hi Graeme, yes, but the pixel contents are the property of the commit. They are not the property of wl_surface or wl_buffer, both of which change content during their lifetime. The only concept we have that matches the content lifetime at all better is a "commit". This is why buffer scale (HiDPI) and transform are also set up on commit and not with wl_buffer. > > The proposed extension > > language models that mechanism correctly by referring to > > "double-buffered state". I can't think of better wording for this, the > > term double-buffered state has grown that special meaning when talking > > about Wayland. > > That's not how I see it. "Double buffered state" just seems to be > a term covering the piecemeal assembly of the various bits > of information needed for an atomic update to the output state > (i.e. what happens between attach and commit). Yes. > Yes, you could do this by treating the source colorspace as just > another bit of information to be assembled, but it's an unnatural way > of doing things, something that becomes clear if you consider > re-using a buffer and its contents for some other update. As a Wayland protocol designer, it is the natural way to me. That said, this may be purely because I've accustomed to the existing practises. > > More precisely, a wl_buffer is a chunk of memory with a size and pixel > > format, and they get re-used all the time. If a client changes the > > color properties of the content but not the pixel format, it likely > > will not allocate a new wl_buffer to hold it. All client frameworks aim > > to re-use existing buffers as much as they can, because destroying and > > allocating new ones takes effort. > > Sure, so the wl_buffer would have its color profile re-set if the > color encoding of new pixel values is different. This is a perfectly > natural time to do this (i.e. say loading an image from > a .jpg file that is tagged with a different colorspace) Conversely, > if the contents were to be re-used, there is no need for the client > to have to keep track of the colorspace when submitting the buffer > as an update, since as a property of the wl_buffer, it tracks right > along with the pixel values. I don't think that works in practise for one huge awkward reason: EGL. When an application uses EGL to deliver its contents to the screen, the application code will never even see a wl_buffer at all. The closest thing the application has access to is wl_surface. There simply is no opportunity to attach anything to a wl_buffer, because those are completely hidden inside the EGL implementation. Making an EGL extension to be able to drive specific Wayland protocol through EGL is not worth it. I do appreciate your thought. Without EGL it would have been worthwhile to look into. Thanks, pq
pgp7Gp8rbmQaC.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
