<div dir="ltr">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.<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, May 2, 2013 at 8:58 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Wed, 1 May 2013 17:03:30 -0400<br>
Kristian Høgsberg <<a href="mailto:hoegsberg@gmail.com">hoegsberg@gmail.com</a>> wrote:<br>
<br>
> On Mon, Apr 22, 2013 at 01:30:28PM +0300, Pekka Paalanen wrote:<br>
> > On Fri, 5 Apr 2013 14:23:50 -0500<br>
> > Thomas Daede <<a href="mailto:daede003@umn.edu">daede003@umn.edu</a>> wrote:<br>
> ><br>
> > > I am not sure that doing the color conversion in the compositor<br>
> > > is the correct place. Some of it has to be there to support vcgt,<br>
> > > but for more general conversions, it gets complicated quickly.<br>
> > ><br>
> > > Color correction is most important for artists doing work in<br>
> > > something like the GIMP. Programs like this (as of GIMP 3.0, at<br>
> > > least) generally work in higher bit depths - 16 bit, half float,<br>
> > > or sometimes 32 bit float. It's much better to do conversion in<br>
> > > the higher bit depth, then dither to the final display depth.<br>
> > > Doing this with the compositor involves supporting all of these<br>
> > > texture formats for subsurfaces - also, the toolkit has to<br>
> > > support subsurfaces, because generally the UI will be some lower<br>
> > > bit depth, or not need correction.<br>
> > ><br>
> > > Converting bit depths in the compositor would also require an<br>
> > > extra buffer allocation and copy in the compositor.<br>
> > ><br>
> > > RGB images are also not the only thing that needs to be color<br>
> > > corrected - for example, 10bit YUV video streams might want to be<br>
> > > color corrected too. If we were to go as far as converting bit<br>
> > > depths in the compositor, it wouldn't be much to add this.<br>
> > ><br>
> > > I think that providing color space regions to the client,<br>
> > > relative to the client's buffer, including vcgt settings, would<br>
> > > shove a lot of complexity away to clients that are already used<br>
> > > to dealing with it.<br>
> ><br>
> > I'm not sure we can do that. The regions can be arbitrarily complex<br>
> > and non-linear shapes.<br>
><br>
> It's not too different from how we handle opaque regions.  We split up<br>
> the surfaces into opaque and transparent parts and render them using<br>
> different shaders already.<br>
<br>
</div></div>Sorry, I read "providing color space regions to the client" as "the<br>
server determines the areas of each output overlapping with the<br>
surface", and communicated that to the clients.<br>
<br>
If the regions are communicated from clients to the server direction<br>
only, then nevermind my comment.<br>
<br>
<br>
Thanks,<br>
pq<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br></div>