[Cairo] Color transforms

Carl Worth cworth at east.isi.edu
Thu Jul 17 01:28:18 PDT 2003

On Jul 16, Bill Spitzak wrote:
 > 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);

The idea I've started developing in the current API is that the device
is specified by creating a device-specific cairo_surface. Then, one
can set this as the active surface using cairo_set_target_surface.  
That way, the device is definitely part of the state as you propose.

Also, there are convenience functions cairo_set_target_* that both
create the device-specific surface and set it as the target.

One idea that should be possible with this approach is graphics
operations using surfaces from separate devices, (think compositing
images from two different X servers for example). That could be a lot
of fun if we can get it to work.

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

I'm not sure this is necessary. I think the semantics would get pretty
muddled if there were an implicit reset of the graphics state when
changing devices. The worst part I can think of is that the frontend
will have to keep some state, (like the clipping path), that may also
be stored in the backend. That doesn't sound fatal to me.

And if there are efficiency problems, the user can always do the reset
manually, (or use a separate cairo_state object), or whatever.


More information about the cairo mailing list