[cairo] Save cairo_surface_t!
otaylor at redhat.com
Thu May 5 15:41:19 PDT 2005
On Thu, 2005-05-05 at 17:29 -0400, Carl Worth wrote:
> To me, that just looks like making things harder than they should
> be. I'm getting more and more tempted by the proposal to eliminate
> cairo_surface_t from the public API, which seems a more complete
> solution than just adding cairo_create convenience functions.
I apologize in advance if this is a rather disproportionate
response to an off-hand idea :-)
While I have some reservations about the idea, which I'll get to
below, I think it's probably a perfectly logically consistent
way to set up a library. But isn't it really late in the game to
make this change?
- It's going to require much significant changes to
every user of cairo than the cairo_create() change.
(Not just mechanical, but structural)
- It's going to require significant changes to every cairo
language binding (cairo_t becomes polymorphic).
- There's not going to be any time to get a lot of experience
with it before we API freeze.
I basically don't see how you could do this without a least a
month of extra time before cairo 1.0. Probably more.
To get to some of my specific reservations:
- The nice thing about the pattern of creating a new cairo_t
is that it naturally goes out of scope in memory managed
cr = window.create_cairo_context()
# draw with cr
cr = window.get_cairo_context()
# draw with cr
[ OK, in non-deterministic GC languages, the first one
needs a cr.finish(), but that's fixable eventually ]
- In general, if you keep cairo_t objects around for the life of a
program, you'll probably be leaking state out of your drawing
functions that you don't mean to leak.
We'd have to promote the idea that you always should
cairo_save() *before* you begin drawing.
- cairo_t adds significant weight over cairo_surface_t when
creating surfaces purely to act as sources. (As will happen
frequently in GTK+)
- The whole idea of source patterns gets really weird.
cairo_set_source_cairo (cairo_t *cr, cairo_t *other_cr);
? And what (if any) parts of other_cr's gstate affect
- If we ever allow external surface types, the API is going to
be awful, since we will have to export the internal
cairo_surface_t at that point, and backend implementations
will have to supply bits of the cairo_t API and bits of
the cairo_surface_t implementation, which really doesn't
fit standard OO principles.
I probably could keep going, but I'll stop there, since I don't want to
distract from my main point: this is a major change, and isn't going
in the direction that people trying to use cairo need: convergence to a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050505/6dd9f0d1/attachment.pgp
More information about the cairo