[cairo] Save cairo_surface_t!

[Owen Taylor]

On Fri, 2005-05-06 at 15:45 -0400, Carl Worth wrote:
> 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.

I'm going to dispute this. We have relatively extensive experience
with the current API. We have *zero* experience with the proposed
API. If the current API was in some way not workable, if we had ample
evidence that people just couldn't figure out the whole context vs.
surface thing, then it might be worth making a change.

But other than that, I think we are at a point where we have to
proceed with the API we've been refining for the last several years.
The 1.0 release isn't a single point in time, if we keep making
changes right up to the last moment, we'll end up making changes
we'll regret.

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

Still, it requires moving lots of stuff around.

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

Both of those could be implemented above either underlying API,
yes. But there is an assumption that I'm making: using a single 
cairo_surface_t for multiple adjacent drawing operations is an
efficiency win. (And I think it is ... especially for things like
no-RENDER Xlib.) 

With that assumption, you can't do the create() version without
an exposed cairo_surface_t. 

The argument I'm making is that the get() version which is forced
upon you results in a problem of state leakage, and thus forces
the save()/restore().

> 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 all the GTK+ work I've done so far, cairo_surface_t comes up only
rarely ... basically only when using surfaces as sources not
destinations.

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

No, not at all. Leaving aside efficiency, some surface types
*can't* just be created on the fly. (An image surface, say)

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

If, not, I'll keep trying :-)
						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/20050506/b583cb25/attachment.pgp