Thomas Daede wrote:
I am not sure that doing the color conversion in the compositor is the correct place. Some of it has to be there to support vcgt, but for more general conversions, it gets complicated quickly.
Hi, The expectation is that vcgt is per output (ie., it's loaded into the display cards RAMDAC), or loaded into the display itself using DDC. The display device color profile assumes this. So vcgt shouldn't need shaders.
Color correction is most important for artists doing work in something like the GIMP. Programs like this (as of GIMP 3.0, at least) generally
As well as this, there is a desire to color manage all GUI elements on a wide gamut display, to avoid a rather garish and hard to read result.
I think that providing color space regions to the client, relative to the client's buffer, including vcgt settings, would shove a lot of complexity away to clients that are already used to dealing with it.
One of the things driving the idea of tagging a colorspace and letting the display system handle color management by default, is that many/most applications don't deal with it. So I think that the idea of shoving off the learning curve about color to a larger group of applcation writers is not likely to be successful.
This is the correct way, I think. Splitting surfaces by monitor also has other unrelated benefits, like being able to sync separately to each monitor - it probably should go somewhere else.
Application writers particularly do not like dealing with the messiness of color managing their graphics elements when they happen to fall across more than one output. A number of applications get color management right on a single display, and fail badly with more than one display. Graeme Gill. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
