[cairo] Cairo gstate objects
spitzak at d2.com
Thu Jun 16 13:52:06 PDT 2005
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:
> 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
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
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
More information about the cairo