[cairo] Re: On recovery from errors in cairo (was: cairo reset)

Carl Worth cworth at cworth.org
Sat Sep 23 13:06:54 PDT 2006

On Sat, 23 Sep 2006 11:03:15 -0700, "Mike Emmel" wrote:
> of reasons. So the the code and the design is increadibly fragile. Its
> a hack documented or not is irrelevent.

Sure, my simpler loop is more fragile. I'm glad to admit that. I liked
it because it made writing simple test cases easier. I don't think
that new users should expect it or rely on it. It's much more natural
(and less fragile) to simply use move_to before line_to anyway.

But it would be no less fragile to depend on an implicit (0,0) than to
depend on in implicit line_to -> move_to conversion.

If operations are performed that depend on the state current point
without taking care to ensure that state is as expected, then there's
some fragility here.

But I really don't see what all the fuss is about. Just call move_to
and you can just never touch this corner case and can ignore how cairo
treats it.

> Like I said in my big long winded post Cairo is not ready yet we can
> either fix it now or at some point a fairly incompatible major release
> will occur I've been programming long enough to feel very comfortable
> to predicting this.

I'd be interested in hearing more details from you on what
API-breaking changes you see necessary in cairo. The long-winded post
just has additions. The issue here would be a change, but it's to an
area of cairo that is 100% avoidable (and we both agreed _should_ be
avoided anyway). So that's certainly nothing worth breaking cairo

>                     I don't understand why there is so much pressure
> to finalize cairo since its just barely reached the point that apps
> can exercise most of the api in a real world setting.

There's no reason to speak about this in the future tense. Cairo's API
is already advertised as stable. You are free to disagree with us on
the timing decision there[*], but the fact is that it's done and the
only question is what we will do in the future.

We can easily make new additions to the API and we can also deprecate
functions if necessary. I really don't expect to have to throw the
interface away and start over any time soon.


[*] Personally, I think freezing when we did was extremely
valuable. It helped a lot for getting some important GTK+/GNOME
adoption that is bearing fruit now with things like librsvg,
poppler/evince, and the various cairo-based GTK+ canvas efforts. It
also helped a lot in getting bigger projects like Mozilla and
OpenOffice.org to seriously look into cairo adoption.

And it's not as if we just arbitrarily slapped a "1.0" label on the
thing. We did sit down and take a serious look at the API, identified
several problems, and then spent several months of hard work fixing
everything that was identified. See the many "API Shakeup" mails that
started in February of 2005:


and continued until the first stable 1.0 release in August.
-------------- 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/20060923/dc1b248f/attachment.pgp

More information about the cairo mailing list