[Cairo] Suggestion for replacing cairo_copy with set_gstate.

Bill Spitzak spitzak at d2.com
Fri Sep 26 15:12:40 PDT 2003

What I was recommending is that there only be cairo_t objects avaialble to 
the interface. The cairo_gstate is entirely internal.

> Perhaps instead we just want a single function to copy the graphics
> state from one cairo_t to another. Perhaps drop cairo_copy and add
> something like:
> 	cairo_set_graphics_state (cr, copy);

Yes this is exactly how I think this should be done, though in some email I 
was writing I used the name cairo_copy_state(cairo_t* to, cairo_t* from).

> And then if the user wants to hold on to just the graphics state, they
> can just use a proxy cairo_t for that.
> Does that make any sense? Hopefully I'm not talking in circles.

This exactly matches what I'm thinking. This would remove any need for any 
references to gstate objects to be passed to/from cairo calls. I think all 
the interface can be done with cairo_t objects.

I'm also wondering if the "surface" object is needed. I could see instead 
that you use a cairo_t object whenever a surface is needed (such as the 
source for a comp), the surface being of course the current surface of that 
cairo_t's top gstate. Plausable advantages are the ability to push/pop the 
source for operations, or to refer to the CTM or other state of the source, 
but mostly it is to reduce the interface to a single object. Something about 
this idea appeals to me, though I'm not sure what.

> This goes to the issue of error handling. See my future email. ;-)

Yes I read that, seems like a good idea. Otherwise people may never notice 
that they are producing errors. One thing though: if errors stop push/pop 
from working, it will be difficult to get back to a known state. Then again 
doing a mismatched set of push/pop would also be an error and cannot be 
recovered from. Perhaps the "clear errors" function should also clear out the 
stack and only keep the stat the cairo_t was created with. Alternatively 
there can be no way to clear errors except to destroy the cairo_t, though I 
can see that being a pain and force some libraries to have to wrap the 
cairo_t pointer in another object.

PS: I finally have a RedHat 9 machine so I will be able to compile and work 
on this stuff, instead of just blathering on about it here on the mailing 

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

More information about the cairo mailing list