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

[Carl Worth]

On Mon, 25 Sep 2006 12:33:36 -0700, "Mike Emmel" wrote:
[Snip a lot of irrelevant content. It really would help if you would
only copy text that you are specifically replying to.]

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

Nokia has provided me with a Nokia 770 and is in the progress of also
providing one to OSDL for their automated testing of cairo through
crucible. See:

	http://crucible.osdl.org/runs/cairo_report.html

(We don't quite yet have lovely performance charts there yet, but all
of the hard parts of doing that are in place.)

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

Yes, testing the new tessellator on arm will be interesting. I was
under a mistaken impression that the old tessellator was all
fixed-point, but it turns out it was using floating-point down deep in
the implementation (oops!). So the new tessellator (which _is_ fixed
point) should be quite interesting---particularly when I fix it to use
only 64-bit rather than 128-bit arithmetic when possible.

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

What does that mean exactly? You're willing to hack cairo to suit your
needs? Or you're willing to link to symbols that we aren't advertising
as part of the stable, public API?

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

Yes, I'm familiar with the tiger. But how does rendering an SVG
example like the tiger necessitate copying of a path from one context
to another. That's the part of your use case that I still don't
understand. Can you explain more specifically how you are using
multiple contexts for this file, for example?

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

A tessellated path only makes sense for a backend that accepts the
stream of trapezoids, (which is currently only the Render
backend). And then there's the fact that we have plans for exploring
having cairo's xlib backend not pass trapezoids to the X server at
all.

Meanwhile, some people have proposed some much crazier ideas around
caching geometry, (referencing papers showing how one can compile
programs for the video hardware that allow a path to be nicely
rasterized at various scales).

So it would be nice if any scheme for capturing and caching state
such as "tessellated path" would also be general enough for any other
kind of bizarre, backend-specific representation of a path. And it
would be nice if the API was still guaranteed to work for any backends
regardless of their capabilities.

So here's the germ of an idea that might be suitable for that:

Augment the current pair of cairo_copy_path/cairo_append_path with
additional or new functions that would return/accept an opaque object
representing the path (a "cookie") along with the path data
itself. This request for the cookie would allow a backend to do any
potentially expensive setup for the path and cache its
representation. Then, when cairo receives a path+cookie, then if the
cookie describes an object suitable for the current backend, and it is
present in that backend's path cache, then it simply uses the cached
path, (and ignores the path data). Otherwise, cairo still has access
to the raw path data and can use that.

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

What's new is a better implementation of the algorithm for finding
intersections among a set of line segments. As for computing
trapezoids from the intersected line segments, there's nothing new,
(it's simply scanning from top to bottom, and at each new Y value for
an intersection or edge termination, scanning out trapezoids from left
to right).

So there's definitely a lot of room for doing something more clever
there. An obvious first step would be to make the left-to-right pass
happen only at each scanline, rather than at every intermediate Y
value. This would allow for generating large, pixel-aligned trapezoids
for large, fully-covered interior regions of the shape. For example,
the tessellation of a large circle would benefit significantly from
that.

But, once we've got all of that in place, perhaps it would be much
better to just rasterize that scanline directly from the intersected
edges rather than generating trapezoids, having them individually
rasterized, and then summed back together.

So that's some of what I referred to above about upcoming experiments
in eliminating tessellation from cairo's pipeline.

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