[cairo] Save cairo_surface_t!

[Owen Taylor]

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
   languages:

    def draw_on_window(window):
       cr = window.create_cairo_context()
       # draw with cr

   Compared to:

    def draw_on_window(window):  
       cr = window.get_cairo_context()
       cr.save()
       # draw with cr
       cr.restore()

   [ 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 
   the source?

 - 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
stable API.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050505/6dd9f0d1/attachment.pgp