[Cairo] Semantics of cairo_copy changed in 0.1.7

Owen Taylor otaylor at redhat.com
Tue Sep 30 18:19:40 PDT 2003

On Tue, 2003-09-30 at 15:04, Carl Worth wrote:
> On Sep 30, Carl Worth wrote:
>  > 	void
>  > 	cairo_copy (cairo_t *dst, cairo_t *src);
> I've gone ahead and committed this (0.1.7).

I'm having a little trouble figuring out the motivations from reading
back over prior mails - Carl said:

> The issue is that there is no way to replace en masse the contents of
> the current graphics state inside a cairo_t. This deficiency has
> already forced one user to ignore the stack inside cairo_t and
> resort to maintaining a private stack of cairo_t objects created via
> cairo_copy. That doesn't seem ideal.

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.

Maybe someone can fill in the details a bit and unconfuse me?


gdk_gc_copy() (similar to this) was recommended as prior art by Gustavo,
but frankly, the gdk_gc_copy() prototype is simply a mistake. I think it
was set up that way in analogy to XCopyGC (which is a bit more general,
and thus perhaps more useful), but you won't find another copy operation
of this nature in the GTK+ stack. I don't think I've ever seen a use of
gdk_gc_copy() not immediately preceded by a gdk_gc_new().

More information about the cairo mailing list