[Cairo] Color transforms

[Bill Spitzak]

On Wednesday 16 July 2003 07:12 pm, David Forster wrote:

> > Secondly I would place some (maybe a lot) of Cairo's logic in the
> > device-independent portion:
>
> PostScript/PDF are very capable targets.  I don't think there's going
> to be much that's device-independent...

Yes I am thinking now that almost everything should be in the 
device-dependent part. If it is in the device-independent part then it 
indicates that perhaps Cairo is too high-level.

The main thing that definately must be device-independent is some portion of 
the save/restore state, because I think the "current device" should be part 
of the Cairo state. However the devices themselves must have state that has 
to be saved/restored as well so they must do part of it.

The only other thing I am considering (because in a similar library I am 
desiging this turned out to be vastly easier) is to make the device-dependent 
part only accept paths made of straight lines. curveto would not be a virtual 
function. This requires that transformations be done device-independent so 
the curveto implementation can determine how many straight lines to break the 
line into. And apparently it will require special line join types so stroke 
can be done correctly, unless stroke itself is device-independent...

The main advantage is that other curve types (ie cubic sections and splines 
of other orders) can be added without modifying Cairo or doing complex math 
to convert them to the closest Bezier.

There are obvious disadvantages to this as well, primarily that any faster 
solution by the device itself is impossible.

> Where does Cairo_Xlib_Engine fit into
> this?  How do I override functions?  How do you efficiently get each
> engine's state to it without doing C++ subclassing, which requires
> prior knowledge of what you are subclassing?

I would recommend that functions be overridden by writing an entire wrapper 
engine for another Cairo engine. It has to implement all the calls and call 
the other one for each of them, modifying the color or whatever before doing 
so. The only public interface and the only thing you can subclass is the 
generic engine. The existence and implementation of Cairo_Xlib_Engine is 
totally hidden in the xlib version, the only public call is something like:

Cairo_Engine* cairo_create_xlib_engine(XDisplay, XWindow, XColormap);

> There's no reason to reset the primary engine unless you're changing
> it, which doesn't seem useful.

That wasn't too clear. What I meant is that when you change devices in Cairo, 
you should always get the identity transformation and everything including 
the clip set to default values. They are *never* inherited from the previous 
engine or the previous state of the new device. This I think is necessary for 
efficiency and to make implementing devices easier.

-- 
                   ,~,~,~,~ ~ ~ ~ ~
     /\_       _|_========___         Bill Spitzak
 ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak at d2.com