[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 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?
>
Yes I'm willing to link in private symbols. I don't consider the needs of a
SVG engine or say pdf render the same as those of a  human programmer.
And breakage between cairo versions is not a issue since obviously I'd
statically link for shipping or otherwise control the version. Webkit already
static links by default.

> > 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?
>
Sorry I've not got my SVG implementation integrated in WebKit just yet.
What I did instead of creating my own path structure is use a fake cairo_t
with a 1 pixel surface as a path when its rendered I have the choice of copying
out the path structure and feeding it to the real cairo_t or do what I
did for a quick
perforance test just reset the path pointer on the destination and draw.
SVG of course does paths as first class objects and you hand them to
the surface to render so I end up having paths defined without knowing
the target.
But like I said I think the better approach is to deal with the tesselated path.

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

What about my idea of treating this as a different type of object I think
its close in concept to a pattern.  I'd say that people using this form would
be in control of determining if its still valid and the user would drop back
to the original path data. Since they control the state changes they would know
if some change invalidated the internal form.
We just need to understand what changes would require you to
retesselate a path. Thats my question. Does a affine transform cause
it to be invalid.
Obviously translations should not but a rotation would cause you to
want to retesselate ?  In any case I don't think we need cairo to keep
the orginal path data
if your using the cache it but it should be able to determine if a
operation invalidates the cache the concept is just and extension of a
glyph cache.


> > 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.
>
I don't know :)
A edgelist would probably be more useful now that you mention it.

In the past what I did was have a single data structure that held rectangles
and edgelists. You would coalesce the rectangles thats easy. I bailed on the
edge simplifying the edge lists. I also had higher level notation was
complex polygons and rectangles if I knew they were not intersecting.
Since you can get
a lot of rectangles and those can be drawn fast detecting those and extracting
them was the most important thing for me. EdgeLists are just more compact
then a lot of single pixel rectangles/scanlines.

The key of course is that you have already eliminated all the
intersections once thats done then rendering is pretty fast I did not
handle this well at all but cairo does a good job. So my suggestion is
you eliminate intersections first extract as many multi pixel
rectangles as possible then consider the format for the rest of the
information with edglists being a pretty good starting point. I did
not do a good job of antialiasing either but since the data structure
should be sorted you know if your on a common side.

I hope this is useful ?

Mike






> -Carl
>
>
>