[Cairo] Suggestion for replacing cairo_copy with set_gstate.

[Keith Packard]

Around 21 o'clock on Sep 26, Banlu Kemiyatorn wrote:

> I'm currently using cairo_copy for gstates' stack management without being
> able to take fully advantage of cairo_save and cairo_restore because it
> lacks of set_gstate. cairo_copy by itself is obscure, since it cannot hint
> user that it didn't copy the gstate stack.

The fact that cairo_copy doesn't really copy the whole cairo_t (it
duplicates the top gstate and drops the rest) seems like sufficient
justification for some kind of change, the question is precisely what that
change should look like.

A 'cairo_t' object holds only two things right now -- a stack of
cairo_gstate_t objects and the library status.  One easy suggestion would
be to eliminate the stack of gstate objects and make the application
developer hold the cairo stack itself -- cairo_t then becomes precisely
cairo_gstate_t.  This exposes two problems:

 1)	applications cannot use the save/restore paradigm without
	creating a stack themselves (either with local variables on the C 
	stack, or an explicit linked list).  This would be an
	annoyance, but probably not a sigificant one as libraries exposing
	a stack of graphics states to applications would presumably already
	have a stacked data structure to hang the cairo_t from.

 2)	The status would become less persistent -- 'popping' a cairo_t
	from an application-specific stack would lose any status 
	information, so application errors would cause local damage instead
	of global damage in the display.  This seems like more of a bug
	than a feature to me; I like the fact that an application fault
	will cause all future output to disappear as that encourages
	developers to fix things (just as IEEE NaN does).

If we care about the more persistent status, then obviously we should 
encourage applications to use fewer cairo_t objects in a single context.
This suggests that we should expose the cairo_gstate_t object so that 
applications will tend to use them instead of their proxy, a cairo_t with 
a single gstate attached.

If we prefer a simpler API, then eliminating the duplicate mechanisms of 
save/restore copy/destroy seems like the better plan.  I've never been a 
huge fan of duplication like this.

I don't know which is the better choice here.

-keith