color management spec

[Zack Rusin]

On Friday 30 May 2008 11:28:38 am Tomas Carnecky wrote:
> Maarten Maathuis wrote:
> > On 5/30/08, Mikhail Gusarov <dottedmag at dottedmag.net> wrote:
> >> Twas brillig at 16:47:54 30.05.2008 UTC+02 when Tomas Carnecky did gyre
> >> and gimble:
> >>
> >>  How do compositing and color management relate anyway? They are not,
> >> and entangling them like this looks like an unnatural (not to say
> >> pereverse) move.
>
> When a compositing manager is running, all the windows are kept
> off-screen and, everytime the window contents change, the compmgr copies
> the frames to the frontbuffer. Compositing managers already use shaders
> for various effects, so sneaking one line of fragment shader comes at
> almost no additional cost.

It's probably worth noting that at this stage some aspects of color-space 
conversion will be already off. Currently all our vector graphics framework 
operate in sRGB/anonymous colorspace. For all intense and purposes while 
blending benefits from this approach, anti-aliasing, which is a physical 
operation, should really be done in linear color-space. The reality is that 
for performance reasons that has never been done especially since a non-lossy 
conversion between sRGB and linear RGB would require (iirc) 10bpc. 
So the fact that you only have a 32bpp pixmap with the contents already 
creates a problem. If your display uses xvYCC (x.v.Color) then if you're 
composing 32bpp sRGB pixmaps you've already lost the battle.
Before doing anything else it'd be probably worth trying to figure out how to 
at least let applications use more than 32bpc for offscreen.

So yea, I think it's a two step process: 
a) we need to actually allow creating arbitrary color-space offscreen 
renderings, which would make sense in graphics toolkits,
b) something can map those offscreen to the  output.
Without both it won't work. And since I'm assuming you won't tackle "a", let 
me just point out that Qt doesn't use subwindows (the exception being things 
you xembed).

z