[RFC PATCH 1/6] Add colorcorrection protocol

[Pekka Paalanen]

On Mon, 31 Mar 2014 09:25:34 +0100
Richard Hughes <hughsient at gmail.com> wrote:

> On 31 March 2014 08:46, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > how much data can an ICC profile be?
> 
> Printer profiles can be several megabytes in size, but display
> profiles (what will be seen here) are usually in the 20-30kb size
> range.

I do wonder if we will have a problem with the maximum message
size in Wayland. I'm not sure how the maximum is determined, and since
profiles could in theory be very big, I'd propose using an out-of-band
method for transferring that data.

> > Also, what if a client has several surfaces all with the same ICC
> > profile, would it not be useful to have some notion of re-using an
> > already sent and parsed color profile? Otherwise I would imagine lots
> > of overhead if every surface has a private copy of the profile
> > sent over the wire, parsed, and stored in the compositor's renderer.
> 
> I don't think typically they'll be many different profiles in use, on
> a typical system most things will just be (assumed) sRGB to 'n'
> display profiles, where n is the number of outputs.

I take that as "yes, explicit re-use would be very useful" to avoid
parsing, comparing and coalescing at every turn.

> > Is that a reasonable requirement for all compositors that support
> > per-output ICC profiles?
> 
> I think it's a very little amount of work, IMO doing it centrally
> makes a lot of sense as some bits are tricky to do correctly.

"Tricky" should be solve by shared libraries rather than a daemon,
IMHO. I'm more concerned about the amount of work the compositor will
be doing, not the work for implementing it. I think such color space
conversion should be accounted for the client, i.e. done in the client.
It would be wasteful, if a compositor needs to compute the source
conversion every time it just repaints the screen, even if the content
for a color-managed surface has not changed. I'm assuming a compositor
would be texturing directly out of a client's buffer.

I would also like to have room for compositors that blend in a
non-ideal color space. Having a separate blending color space is
essentially an additional copy, AFAIU, which is a pretty high cost for
something, whose result any single client cannot assume at all, anyway.
I still think that if a client needs the result of blending non-opaque
pixels to be guaranteed, it should do it itself and not rely on the
server.

> Overall, I'm very happy to see someone pick up this work. Thanks.

Indeed.


Thanks,
pq