[RFC wayland-protocols v3 1/1] unstable: add color management protocol

[Pekka Paalanen]

On Wed, 3 Apr 2019 12:37:56 +1100
Graeme Gill <graeme2 at argyllcms.com> 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
-------------- 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/20190403/88f59b70/attachment-0001.sig>