On Fri, 5 Apr 2013 14:23:50 -0500 Thomas Daede <[email protected]> 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. > > 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 > work in higher bit depths - 16 bit, half float, or sometimes 32 bit > float. It's much better to do conversion in the higher bit depth, then > dither to the final display depth. Doing this with the compositor > involves supporting all of these texture formats for subsurfaces - > also, the toolkit has to support subsurfaces, because generally the UI > will be some lower bit depth, or not need correction. > > Converting bit depths in the compositor would also require an extra > buffer allocation and copy in the compositor. > > RGB images are also not the only thing that needs to be color > corrected - for example, 10bit YUV video streams might want to be > color corrected too. If we were to go as far as converting bit depths > in the compositor, it wouldn't be much to add this. > > 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. I'm not sure we can do that. The regions can be arbitrarily complex and non-linear shapes. I also do not believe that solving the color correctness problem for a single surface spanning more than one monitor is worth all the pain and special cases, unless the color correction is done in the compositor. > > The compositor should be able to draw N polygons for the N > > intersections of a surface with each output, each using a different > > shader? You absolutely do not want to put an if based on a pixel > > value into a glsl shader. It is really slow. > > 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. Weston already does it like that. Each output is a framebuffer, the desktop as a whole is not. Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
