[Openicc] XICC specification draft (Xinerama vs. composite).

[Graeme Gill]

Keith Packard wrote:
> On Mon, 2005-06-27 at 19:42 +0200, Kai-Uwe Behrmann wrote:
>>This implies the color conversion should go in the composite manager, is 
>>this correct? Or do you prefer an other color conversion layer on top of it?

> The whole composite manager architecture is up for discussion at this
> point; we've got lots of things it needs to do, and right now we can
> only really support a single instance.
> 
> In any case, I suspect color conversion would be implemented as pixel
> shaders in a GL-based compositing manager.  This should provide
> sufficient flexibility and performance for most anyone.

There are several levels of possible accuracy/speed that could be
accommodated. For sufficiently similar monitors, perhaps calibration
(ie. vcgt/RAMDAC curves) may be sufficient to allow a single profile
to apply to the group. A simple matrix/curve conversion may suffice
for a larger range of monitors (although performing good clipping
is a challenge at this level.) I would imagine the texture lookup
support in modern GPU's could be adapted to perform a general color
conversion, but often there is a loss of smoothness in using CLUT
based conversions, and I'm not sure what sort of performance hit
would be involved.

To get maximum performance may involve some complexity in the rendering,
and quite a lot of trade-offs to be decided. Obviously color conversion
before rendering is going to be faster for fills of a constant color,
while a every pixel of a raster is going to need to converted. Cases
like blends are more difficult to decide. Does the semantics of the
compositing manager refer to the colorspace the rendering is performed in,
or is this unspecified ? If it is specific, then color conversion going
in and coming out of a blend will be needed. If not, then maybe color
conversion is only needed for the input colors/rasters to the blend (etc. etc.).

Graeme Gill.