Pekka Paalanen wrote: > 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.
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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
