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

[Graeme Gill]

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.

> 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, 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.

> 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.

Cheers,
	Graeme Gill.