I'd suggest that client should use subsurfaces if they want multiple colorspaces in a window. They might have to do that anyway since they may want a different pixel format.
On Thu, May 2, 2013 at 8:58 AM, Pekka Paalanen <[email protected]> wrote: > On Wed, 1 May 2013 17:03:30 -0400 > Kristian Høgsberg <[email protected]> wrote: > > > 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. > > Sorry, I read "providing color space regions to the client" as "the > server determines the areas of each output overlapping with the > surface", and communicated that to the clients. > > If the regions are communicated from clients to the server direction > only, then nevermind my comment. > > > Thanks, > pq > _______________________________________________ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel >
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
