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

[Jim Gettys]

This is one possibility, one not yet (and probably a couple years) from
fruition.

How practical it is (e.g. is the quality high enough) is a different
question.  Which is why I brought up the topic...

			- Jim


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?
> 
> regards
> Kai-Uwe Behrmann
>                                 + development for color management 
>                                 + imaging / panoramas
>                                 + email: ku.b at gmx.de
>                                 + http://www.behrmann.name
> 
> 
> Am 27.06.05, 12:15 -0400 schrieb Jim Gettys:
> 
> > 
> > Xinerama as it currently exists has a number of shortcomings, but
> > many/most people find it useful.
> > 
> > By its nature, however, it is hiding multiple monitors as though they
> > are one: if they are not matched in characteristics, Xinerama present
> > major headaches for people interested in serious color.  It may be that
> > presuming if you are running xinerama that the monitors/flat panels are
> > a matched set is probably "good enough" for people who want to do that.
> > 
> > Another approach to the current Xinerama is possible once the new
> > composite extension deploys widely and our drivers work well for it
> > (right now, only certain X drivers can run composite effectively).
> > We've certainly been talking about the possibility of making xinerama
> > obsolete someday given composite.
> > 
> > For those of you not familiar with composite, here's a thumbnail sketch
> > of how it works:
> > 	When composite is enabled, rendering no longer goes to the frame
> > 	buffer(s); instead, the rendering occurs in offscreen pixmaps.
> > 
> > 	An external application, called the compositing manager, becomes
> > 	responsible for composing the real image in the real frame 
> > 	buffer. (it gets told which windows have what pixels updated), 
> > 	and the compositing manager may add eye candy of various sorts.
> > 
> > One could then have the compositing manager attempt to do a conversion
> > from, say, linear rgb to what the real frame buffer needs to drive the
> > particular monitor with color correction.  This conversion might be
> > different on different monitors that make up the unified "screen" seen
> > by applications. The issue then is whether the resolution of the
> > information in the pixels is sufficient; my intuition is it probably is
> > "most of the time", but probably not for serious applications.
> > 
> > But I'm not a color expert: you folks tell me ;-).
> > 			Regards,
> > 				- Jim
> > 
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc