[Cairo] Color transforms

[David Forster]

On Wed, Jul 16, 2003 at 11:25:40AM -0700, Bill Spitzak wrote:
> backends that are compatable with each other, and avoid the overhead
> of the "virtual function call" on many of the Cairo interfaces.

You mean my find-the-non-NULL loop...You still do virtual calls.
Neither, I think, are that expensive.

> First I would design your structures much like a C++ object, so that several 
> instances can share the "vtable", yet have local "instance variables". 

Yeah, totally right. Opps. ;)

> 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...

> 
> struct Cairo_Xlib_Engine {
[...]
> };
> 
> struct Cairo_Vtable {
[...]
> };
> 
> struct Cairo_State {
>   Cairo_Engine* engine;
>   Cairo_State* previous;
[...]
> };

I don't see how this works.  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?

> void cairo_setdevice(Cairo_State* state, Cairo_Engine* device) {
>   state->engine = device;
...
>   state->vtable->reset(state);
> }

I assumed just new `mini-engines' would be added at appropriate times.
There's no reason to reset the primary engine unless you're changing
it, which doesn't seem useful.

> The other thing I think should be done is make all the
> transformations, and all path construction that is more complex than
> lineto be device-independent.  This will avoid the need to
> reimplement these for every device, and to design the interface to
> allow the addition of new curve types easily.

PostScript/PDF already do a good job of doing curves, though.  You
want those backends to handle this.  If there's anything you don't
like about a particular PostScript implementation, fixing that is
better left to the backend.

-Dave