On Mon, 31 Mar 2014 09:25:34 +0100 Richard Hughes <[email protected]> wrote:
> On 31 March 2014 08:46, Pekka Paalanen <[email protected]> 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
