[Cairo] Suggestion for replacing cairo_copy with set_gstate.
cworth at east.isi.edu
Fri Sep 26 08:49:41 PDT 2003
On Sep 26, Keith Packard wrote:
> If we care about the more persistent status, then obviously we should
> encourage applications to use fewer cairo_t objects in a single
I think the persistent status is an important feature, (which reminds
me I was planning to send a message to advertise this feature better).
> 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.
Can't we really do both? The proposal was to maintain the stack, but
expose the cairo_gstate_t object with a couple of new functions to
manipulate the gstate on the top of the stack:
cairo_get_gstate (cairo_t *cr);
cairo_set_gstate (cairo_t *cr, cairo_gstate_t *gstate);
And with those functions in place the confusing cairo_copy becomes
redundant and we can drop it.
That would allow us to maintain the stack and persistent status. And I
don't see save/restore set_gstate/get_state as redundant, (PostScript
provides the same).
The biggest drawback I see to this approach is that Cairo will be
exposing two different state objects, (cairo_t and cairo_gstate_t).
More objects means more complexity that the user needs to understand
in order to use Cairo. But I'm willing to accept that to reduce the
problems with cairo_copy.
More information about the cairo