[cairo] RFC the idea of n-plane color support

[Ross McFarland]

On Sat, 2004-10-30 at 16:03, Keith Packard wrote:
> Around 17 o'clock on Oct 29, Ross McFarland wrote:
> 
> > basically if you don't support an arbitrary number of color planes cairo
> > couldn't be used as a RIP engine for a printer or printing press.
> 
> Just paint each channel in a separate buffer; if you aren't using a CIEXYZ 
> traceable color space, there's no way cairo can understand what color 
> you're using in any case.

it doesn't need to understand the color, as it doesn't now. it just
needs the ability to pass it along any type of color as an essentially
opaque object. core cairo doesn't know anything about color and
shouldn't, only the backends and apps do. i have a patch that allows
arbitrary color data to flow through core cairo. and it is a trivial
amount of code. the only thing missing from it was a public api to set
those colors (which i would suggest be in a secondary public header,
cairo-color.h etc.) the current rgb paths were intact and in fact
remained untouched.

if you have to paint each channel in a separate buffer (or three to a
buffer) you've considerably reduced performance as all of the
tessellation code, etc. will have to happen multiple times. apps will be
very unwieldy having to manage and keep in sync multiple cairo contexts,
duplicating every operation on each context. that doesn't seem to make
sense when allowing arbitrary color would entail no performance impact
and negligable memory footprint (bytes/color.)

again i don't envision this to be used 99% of the time, in fact i would
imagine most would never know it was there. but it would cost almost
nothing and leave open the possibility of supporting any type of non-rgb
device. 

-- 
-rm
http://www.neces.com/