[RFC PATCH 1/6] Add colorcorrection protocol

[Alex Elsayed]

Pekka Paalanen wrote:

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

Well, with FD passing couldn't fstat be used with comparing st_dev and 
st_inode? That'd give comparison without parsing (although depending on how 
you use the FD you might want the SEAL_* stuff as well.)

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