Carsten Haitzler (The Rasterman) wrote: > wouldn't it be best not to explicitly ask for an output colorspace and just > provide the colorspace of your buffer and let the compositor decide? e.g. if > your window is on top, or it's the largest one, or it's focused,then the > compositor MAY switch the colorspace of that monitor to match your surface's > buffer colorspace, and if it goes into the background or whatever, switch > back? > it can (and likely should) emulato other colorspaced then.
That doesn't seem like color management. Ultimately you arrive at the native display space, so if things are to look as intended, something (application or compositor) should transform from a non-native spaces into the native space. At a practical level, if it is expected that the compositor deals with transparency (which I assume it does), then I'd suggest something simple - compositing in output device space (Isn't that what current Wayland compositors are doing ?), or as a refinement, compositing in a per-channel light linearised space, that is reversible at the bit level. Bottom line is that a color critical application won't use compositor transparency for anything it cares about. > e.g. if buffer is adobe rgb, then switch display to work in adobe rgb but > re-render everything else that is sRGB into adobe argb space... there might be > a slight "flicker" so to speak as maybe some banding appears in some gradients > of SRGB windows or colors are ever so slightly off, but the compositor is > optimizing for the surface it thinks it most important. Sounds cumbersome. It's certainly not how existing systems work. > i really don't like the > idea of applications explicitly controlling screen colorspace. I'm not sure what you mean by that. Traditionally applications render to the display colorspace. Changing the display setup (i.e. switching display colorspace emulation) is a user action, complicated only by the need to make the corresponding change to the display profile, and re-rendering anything that depends on the display profile. Graeme Gill. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel