[Cairo] Color transforms
spitzak at d2.com
Wed Jul 16 20:13:09 PDT 2003
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
More information about the cairo