[Cairo] Semantics of cairo_copy changed in 0.1.7

[Keith Packard]

Around 21 o'clock on Sep 30, Owen Taylor wrote:

> But I'm really not sure how to interpret that. If you mass replace the
> contents of a cairo_t how is that different from creating a new cairo_t?
> malloc() / free() are not expensive, and I don't think it's worth giving
> up API simplicity to save a few.

the new copy function replaces only the top of the destination gstate 
stack, leaving underlying elements in place.  This allows you to save/
restore the gstate with:

	cairo_t	*temp = cairo_create ();
	cairo_copy (temp, cs);
	<muck with cs state>
	cairo_copy (cs, temp);
	cairo_destroy (temp);

The old copy function wouldn't permit this usage as it wouldn't permit the 
second cairo_copy.  The alternative (and not a horrible one in my opinion) 
is to expose the cairo_gstate_t with:

	cairo_gstate_t	gstate = cairo_current_gstate (cs);
	<muck with cs state>
	cairo_set_gstate (cs, gstate);
	cairo_gstate_destroy (gstate);

This exposes a new datatype (cairo_gstate_t) along with a single
gstate-specific function (destroy, oh, and we'll probably want
cairo_gstate_ref as well).  I can see the point of the cairo_copy variant
with the simpler object model, but the weird cairo_copy semantics are
likely to trip people up, while the cairo_current_gstate/ cairo_set_gstate
model seems semantically cleaner.

-keith