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

[Mike Emmel]

On 9/23/06, Carl Worth <cworth at cworth.org> wrote:
> 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
> about.
>
> >                     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.
>
Okay maybe I'm being to hard  I agree.
A short answer here.

In SVG you wan't to create paths then stroke them. Most of my problems
are actually with the path part of the api right now.
If your willing to consider the changes I need to make to add fast routes
for stroking and filling existing paths then this is what I'd like to do.

Api wise the problem is you already exposed a public path struct that has
to be converted to internal form.

I wan't to add ways to work with the internal form without conversion between
multiple contexts. If we add this there will be similar but different
api's because
of the internal/external path object which are different.
Later once I get deeper into SVG  I can already see a number of concepts
that it would be not to implement inside of cairo but I don't have how
to do this firm and it would only come after extensive performance
testing indicated that they were a big win.

So simple question are you willing to consider exposing the internal
path as and opaque object with functions to manipulate it and if so
what would you want to name it.

Mike


> -Carl
>
> [*] 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:
>
> http://lists.freedesktop.org/archives/cairo/2005-February/003036.html
>
> and continued until the first stable 1.0 release in August.
>
>
>