On Mon, Apr 22, 2013 at 01:30:28PM +0300, Pekka Paalanen wrote: > 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.
It's not too different from how we handle opaque regions. We split up the surfaces into opaque and transparent parts and render them using different shaders already. Kristian _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
