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

[Graeme Gill]

Pekka Paalanen wrote:

Hello Pekka,

> yes, but the pixel contents are the property of the commit.

I don't see that - a wl_buffer appears to be quite independent of
a commit. For instance, the screencopy protocol creates a wl_buffer
without any reference to a wl_surface, and a color managed
screencopy buffer should be tagged with the outputs color
profile, so that the client can (say) retrieve the profile
and tag the image file it saves it to.

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

They aren't analogs though. The buffer scale and spatial transform
are both transforms. Conceptually they could be defined as transforms or they
could be derived by combining source and destination state.
For instance, HiDPI scale could be defined as a scale factor,
or as a product of the destination DPI divided by the source DPI. The
transformation is a property of the commit, yes. The source state (for
rendering to output) is a property of the wl_buffer, and the destination
state is a property of the wl_output.

For color management the state in question is the color device profile. The
transform is the result of combining the source and destination device profiles
(using a CMM) into device link transform, something that would happen at commit.

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

>From my perspective, representing the device color profile as an independent
object and having code keep track of it and the corresponding wl_buffer is
kind of the equivalent of "spaghetti programming". It can certainly be made
to work, but it is fragile and hard to maintain, and presents an overly
complex API.

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

>From poking about the code, it doesn't seem to me to be any easier or harder
to deal with EGL than any of the other back end wl_buffer types :- they
are all difficult because of the nature of the current implementation.

It appears that from the Wayland compositor perspective (e.g. Weston),
that there is typically no concrete wl_buffer type - it is just a struct * declaration
and a protocol definition with one request and one event. Individual back end
implementations create their own protocol compatible objects and
cast it to wl_buffer, and therein lies the difficulty.

If wl_buffer was a virtual base class from which the back
ends inherited, then it would be simple to add the color profile
reference to the base class, as well as methods to access the profile.
But as this isn't the case, it currently appears to me that there are a
few possible approaches:

1) Define a concrete wl_buffer type in the compositor, and store a reference to
the back end types in it, along with the color profile reference.
The wl_buffer implementation would have to somehow intercept
all wl_buffer factories return value to wrap them, as well as
proxying the request and event back to them. Any other
protocol messages that pass wl_buffers to back ends would also
have to have the wl_buffer de-referenced somehow too.

2) Alter all the back end wl_buffer types to include the color profile
reference. There doesn't seem to be a mechanism for registering virtual
methods for the compositor implementation to provide access to the color
profile in a way that's independent of the particular back end structure
layout though, so you're left with ensuring binary compatibility of some
kind, something that doesn't seem idiomatic to Wayland (although I have
used it quite extensively and successfully in my C code by way of struct macros),
so some mechanism equivalent to a vtable would have to be added.

3) Extend the wl_buffer protocol to include methods for setting
and getting a color profile object. This then puts it on the
back ends to implement those requests and store and retrieve
the object reference, but implementation then follows the usual
Wayland pattern. Once again, having a way of defining
a base class would ease back end implementors lives, by
allowing them to call common core implementations of these methods, but
if it's a single object to store and retrieve, perhaps the burden isn't
great.

Hard for me to judge amongst these possibilities or to
know of any others, without delving deeper, but intuitively
the last options seems the cleanest. I presume it has core
protocol versioning implications though.

[ Of course every back end will need to be modified to actually
  support the color transform at commit time anyway, at which point
  either it will retrieve the color profile from the wl_buffer. ]

Cheers,
	Graeme Gill.