[cairo] Save cairo_surface_t!

[Carl Worth]

On Thu, 05 May 2005 18:41:19 -0400, Owen Taylor wrote:
> I apologize in advance if this is a rather disproportionate 
> response to an off-hand idea :-)

And I'll apologize for continuing the discussion, even if I end up
mostly agreeing with you. (And, partially, you're falling for my bait
just like I'd hoped---the original proposal hadn't seen a lot of
discussion, but I wanted to see what we could do with the 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? 

If the idea were really a lot better, I think it would be worth it to
make a change now --- since the looming 1.0 release raises the cost of
API changes so much.

>  - It's going to require significant changes to every cairo
>    language binding (cairo_t becomes polymorphic).

Not really. Instead of cairo_surface_t going away, just pretend that
cairo_t goes away and all the structure should be there already.

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

I'm not convinced on this point. But let's try to isolate the benefits
of the change itself, (separate from the painful effects of actually
making such a change). I'm still ready to reject the idea because the
change would be too painful, but I want to understand what we would be
losing if we did that.

>  - 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()

I think this issue of "create vs. get" of a context is orthogonal to
the question of whether the cairo interface requires one or two
objects. I don't see why either of the above couldn't be implemented
on top of either version of the cairo interface.

But, the examples above do make an independent argument that is quite
compelling. Namely, that in toolkits and bindings the second object
that cairo requires, (the cairo_surface_t), can readily be absorbed
into an object that likely already exists to collect all the
window-system-specific data associated with a given surface.

In that case, my two-object concern disappears and we're left with
considering an optimization exclusive to non-toolkit C usage, which is
definitely not the right thing to optimize for.

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

This is "create vs. get" again.

>  - cairo_t adds significant weight over cairo_surface_t when
>    creating surfaces purely to act as sources. (As will happen
>    frequently in GTK+)

It shouldn't be hard to make cairo_t basically free in this case. But
this is the thing that I have always found awkward in this approach.

>  - The whole idea of source patterns gets really weird.
> 
>     cairo_set_source_cairo (cairo_t *cr, cairo_t *other_cr);

This does look bad, and does seem unavoidable.

Do I sound convinced yet?

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050506/40ee4f51/attachment.pgp