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

[Mike Emmel]

On 9/25/06, Carl Worth <cworth at cworth.org> wrote:
> On Sat, 23 Sep 2006 17:56:05 -0700, "Mike Emmel" wrote:
> > 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.
>
> If there are API issues causing real performance problems, then yes,
> we definitely want to hear about those performance problems so that we
> can work together on coming up with any API necessary to fix them.
>
> > Api wise the problem is you already exposed a public path struct that has
> > to be converted to internal form.
>
> Right. We did this quite intentionally as the current internal form
> had two things making it unsuitable for the public API:
>
> 1. It's really hard to navigate
>
> 2. We weren't 100% sure it would never change
>
> Additionally, the problem that the cairo_copy_path API was intended to
> solve was that of getting at the actual data, so an opaque path object
> would not have been sufficient.
>
> There are various performance-specific API calls that have been
> proposed for cairo, (such as a way to achieve the effect of many
> simultaneous calls to cairo_line_to with an array of points), which we
> have intentionally not added to cairo until a real-world performance
> need motivates them.
>
> This strategy of avoiding performance-specific API until there's a
> measured bottleneck that requires it has some benefits. It allows the
> cairo API to be much simpler to maintain. And it allows it to be much
> simpler to use. A particular problem would occur if there were an
> easy-to-use but "slow" API and a hard-to-use but "fast" API. It would
> be unfortunate if users were led to prefer the harder API,
> complicating their own programming, even if the potential speed
> difference might not be significant for their application.
>
> At the same time, this strategy does mean the API isn't optimal for
> performance from the beginning, and we do require users to report
> things back to us, and we'll need to have a fast cycle of getting the
> new performance-specific API out to users once it is shown to be
> necessary.
>
> So there are tradeoffs in this strategy, but it it the style we have
> adopted for cairo development.
>
> > I wan't to add ways to work with the internal form without conversion between
> > multiple contexts.
>
> So the question is: What's the performance bottleneck you are hitting
> here?
>
> I would imagine that the best approach for your code is to use your
> own custom data structures for describing your geometry, (which most
> applications will be doing already since the primitives provided by a
> cairo path are almost always lower-level than what the application
> wants to work with). And then, use cairo_move_to/line_to/curve_to/arc
> to create your paths when you want to draw them.
>
> If you're already doing that, and you are seeing a performance
> bottleneck from the path-creation functions, then please let us see an
> example test case that shows the problem so we can look into it,
> (ideally as a test case in the for described by cairo/perf/README).
>
> > 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.
>
> I'd like to hear more details about the motivating use case first. For
> example, it could be possible that all that is needed is a way to copy
> the path from one context to another without any need for introducing
> a new path type.
>
> As for an external path object with manipulation functions---way back
> in September 2003, (a couple of years before the stable 1.0, and about
> 18 months before the current cairo_path_t), I added an opaque
> cairo_path_t object along with the following functions:
>
>         cairo_set_path, cairo_current_path, cairo_path_create,
>         cairo_path_destroy, cairo_path_move_to, cairo_path_line_to,
>         cairo_path_curve_to, cairo_path_rel_move_to,
>         cairo_path_rel_line_to, cairo_path_rel_curve_to,
>         cairo_path_close_path, cairo_path_current_point.
>
> Here is the proposal I made for that change (and the commit object):
>
>         http://lists.freedesktop.org/archives/cairo/2003-September/000542.html
>         ca1cec0f49f837dbe541fed97280952315d2876c
>
> This API was removed the same day in response to some well-reasoned
> arguments from Keith Packard:
>
>         http://lists.freedesktop.org/archives/cairo/2003-September/000543.html
>         4dc8b3a312d0f390306131006e6d87a25e41ce58
>
> I still agree with his overall analysis, (though we later changed
> things so that cairo_save/restore do not save/restore the path so the
> specific analysis of nested-paths no longer applies).
>
> The thrust of the analysis is that we would only need such API if some
> performance concern demanded it. So, if you think you've got that
> performance concern now, please demonstrate it.
>

First and I have to be opaque but the performance concerns are for running
cairo on embedded arm devices I cannot release any test data at this time.

Next I need to see about getting a device to the main cairo team if
your intrested
in adding a arm device to your performance testing. Maybe someone else
is willing to contribute one. I've seen enough people posting about running on
arm devices that it makes sense to work towards adding at least one as a
test device. In all probability it will take me a while to get a
device but I'll start the process. If someone else provides it please
make sure its reasonably publicly available and open enough to run
Cairo.

Once we have a arm device in your possesion we can talk real numbers
about performance on the device.

Finally I really need to test your new tesselator since this was the
biggest problem  in the past your new work I think changes the
performance profiling significantly. I assumed a better one would be
coming someday, I'm not a complete skeptic :)

Next the use case is not really a public api but to back the svg
engine in webkit.
I've got no problem working with a  internal api in this case and
don't care if it changes performance and memory usage is all that
matters.

Finally I've not worked out the memory usage at each stage and I need
to balance memory footprint vs performance. Simply using cairoint.h and
copying the path pointer from one cairo_t to another gave a nice speed
improvement for the tiger.

http://croczilla.com/svg/samples/tiger/tiger.svg


I've got and outstanding question that I don't have and answer for is
there any reason why tessellated paths cannot be saved ?

I'd really love your input on the tessellated path question. Since I
now plan to work with the path in that form unless someone thinks
there is a reason that I should not. As far as a  possible public api
for it I think it would make sense to consider it
a sort of pattern  similar to a mask. So you have a image mask and this would
be a path or trap_mask ?

Say CAIRO_PATTERN_TYPE_TRAP ?

Also I've not looked into the new tessellator but the old one did not
seem too coalesce  traps does the new one try too  and of course is it
worth it ?









> Thanks,
>
> -Carl
>
>
>