[cairo] Save cairo_surface_t!

[Carl Worth]

On Fri, 06 May 2005 16:14:34 -0400, Owen Taylor wrote:
> I'm going to dispute this. We have relatively extensive experience
> with the current API. We have *zero* experience with the proposed
> API.

Fair enough. The cairo_create(cairo_surface_t*) change was smaller,
and it was still big enough to hide the metrics-without-a-target-
surface problem.

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

Gotcha.

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

Yes, the state leakage makes the usage really messy. I definitely
don't want cairo to feel as fragile as it would when used in that style.

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

Yes. Even when re-working cairo-demo/X11 which has some raw-Xlib
demos, I found that I already had a structure to hold the Display* and
Window/Pixmap and it was just as easy to lodge the cairo_surface_t*
there as well. So no extra object management in the application. And,
as a bonus, the platform-specific portion of the application is
restricted to a smaller portion of the program due to the abstraction
of cairo_surface_t, (a benefit that also argues against the
platform-specific cairo_create convenience functions).

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

I understand this argument better now. Storing surface contents and
storing drawing state are distinct operations. And the programmer will
want different lifetimes for the two operations. So merging the two
cairo objects would fight against that desire.

> > Do I sound convinced yet?
> 
> If, not, I'll keep trying :-)

You win. Good arguments, well presented.

Thanks for the exercise.

-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/20050509/4dc07459/attachment.pgp