[cairo] Cairo gstate objects

[Bill Spitzak]

Carl Worth wrote:

> I still think a reasonable plan is to add an opaque "graphics state"
> object (cairo_gstate_t ? cairo_graphics_state_t ?) with two functions:
> 
> 	cairo_gstate_reference
> 	cairo_gstate_destroy
> 
> And then the copy operation would simply be:
> 
> 	cairo_set_gstate (cr2, cairo_get_gstate (cr1));
> 
> The notion of a "graphics state" must of necessity be familiar to
> cairo users anyway. The documentation will have to describe
> cairo_save/restore as acting on a stack of graphics state objects
> within the cairo_t context. And the current path will have to be
> documented as living inside cairo_t, but not as part of the graphics
> state.

Is this gstate object going to be fixed-size like the ctm?

If not, it may be better to implement only copying from one cairo_t to 
another:

	cairo_copy_gstate(cr2, cr1);

The purpose is to avoid adding a whole api to allocate, free, copy, and 
especially for altering gstate objects. The desire to modfy a gstate 
will lead to almost all cairo calls being duplicated for them. By making 
a program use cairo_t objects instead, they already have the entire api.

Plus they get gsave/grestore for free.

It may be useful to provide a dummy cairo_t subclass that does not draw 
on anything.