[Cairo] Semantics of cairo_copy changed in 0.1.7
Keith Packard
keithp at keithp.com
Tue Sep 30 19:21:35 PDT 2003
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
More information about the cairo
mailing list