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

[Carl Worth]

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.

Thanks,

-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/20060925/a505a54e/attachment.pgp