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

[Pekka Paalanen]

On Thu, 4 Apr 2019 16:47:16 +1100
Graeme Gill <graeme2 at argyllcms.com> wrote:

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

Hi Graeme,

they are analogues. They are not transforms, instead they describe
properties of the image. Buffer scale is not a command for the
compositor scale the image, instead it describes the scale of the image
so that a compositor can present it in a suitable way anywhere. One
could say buffer scale is only half of a transform, just like a color
profile; source state.

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

If a compositor makes a copy of a wl_buffer contents, it will release
the wl_buffer while keeping and using the contents still. Therefore the
color properties must follow the content as the wl_buffer may well have
been destroyed already by the client as a response to the release.

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

The combining cannot be fixed at commit. It happens on composition.

Let's consider a case where a client has committed an image (wl_buffer +
color properties etc.). That image is now in the wl_surface. The
wl_surface gets shown on output 1, for that the compositor creates the
necessary device link transformation and uses it. Then, the wl_surface
gets moved by the compositor and shown on output 2. The compositor
needs to create a new different device link transformation to do the
color mapping. Therefore the device link transformation cannot be fixed
at commit time - not even if you generated one for each output, because
a new output could be hotplugged later.

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

Right now there is no Wayland protocol object that would directly
represent "a frame of content" with all the properties it may have. It
could have been useful, but maybe not avoid the need for
wl_surface.commit because the set of needed state varies and new
extensions will need a point to hook their state updates to. A
wl_buffer is only a part of content - more of an artifact of memory
management, and wl_surface is more than just the content... or is it?

Not having a Wayland object for something does not prevent a compositor
from using an internal object for it. E.g. weston has struct
weston_surface_state.

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

You were looking at client side code, right?

Because server side it indeed is no problem, a Wayland compositor
always implements the wl_surface interface itself, so it has access to
the wl_buffer (though not to all factories of wl_buffers).

The EGL problem is in the client side: a client cannot attach anything
to a wl_buffer if it uses EGL Wayland platform, because it cannot get
to the wl_buffer at all.


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/20190404/6355b419/attachment.sig>