[cairo] Where's the bottleneck in using glitz/cairo/librsvg?

[Carl Worth]

On Mon, 12 Jun 2006 17:58:12 +0200, David Turner wrote:
>
> That's exactly what I plan to do, I'm still on the GIT tutorial and 
> documentation at the moment though :-)

OK. Let us know if you get stuck on anything. We've been picking up
git experience here and sharing hints, so feel free to ask. (We
haven't yet collected our useful hints into a git usage page on the
cairo wiki, but helping a new user through might help us do that---or
push stuff upstream into git documentation as appropriate).

> The patch is an easy way to provide something useful and testable, and 
> to foster comments and analysis.

Certainly. And it is appreciated.

> This requires computing
> one projection and two eclidian distances, which are quite costly 
> operations, even when performed
> with doubles.

Oh, sure. There are huge piles of computation in cairo that have never
been optimized. In almost all cases we wrote the most straightforward
code possible to achieve the correct result, and a lot of it hasn't
been touched yet.

> There are several ways to perform this kind of thresholding using only 
> shifts and adds, due to the
> nature of the bezier curve; however, I haven't introduced it yet since 
> it slightly changes the interpretation
> of the "tolerance" parameter, which could modify the number of points 
> found in a given spline
> decomposition, having the potential to fail the unit test suites which 
> do nothing else than matching
> exact pixel values.

Ahah! If by "pixel-perfect" you were referring to the unit tests, then
perhaps they've given you the wrong impression. There is no
requirement that cairo compute these exact results forever. The test
suite is definitely more exacting than the actual requirements we have
for cairo.

So if you were to code a faster implementation of the spline
decomposition that still respects the tolerance value, it is not a
problem at all if it produces different results. I'm quite comfortable
installing new reference images across the board. If we're convinced
about the numerical aspects of the code, and we expect it to change
the details of the rendering, it's usually quite straightforward to
look through *-diff.png, see that it's just subtle edge effects, and
then copy all the *-out.png images to *-ref.png for new reference
images.

And it would be worth tweaking the test suite to try to get it to
match our actual requirements better. But it's hard to specify what
they are exactly. For example, the extreme pickiness of the test suite
has been useful for finding fairly deep problems in the code. There
was a case where the tessellation was "leaking", (which is something
that is totally unacceptable) but it only resulted in background
pixels differing in a single bit from the reference images.

So just putting a larger threshold on the image comparison would not
be sufficient. What might work is doing edge detection on the
reference images and allowing tiny variations in edge pixels only or
something like that.

> First of all, I've said lowering rendering constraints (e.g. getting rid 
> of abutting edges, which has nearly
> no practical value in an alpha-based world anyway, except if you're 
> generating an alpha mask), not
> lowering the quality of the output.

What abutting-edge rendering constraint are you referring to here?

Do you mean the requirement in the Render extension that two
trapezoids that share a common edge can be rendered incrementally so
that any common-intersected pixels sum properly without seams?

If so, that's a rendering constraint of Render that cairo's current
(tessellation-based) implementation takes advantage of. But that's
never been a constraint that cairo has enforced for the geometry the
user provides. So it's definitely not going to interfere with any
optimization strategies.

So maybe I'm just saying that we're already where you want us to be as
far as that kind of thing.

> Second, you must consider the possibility that some of Cairo's current 
> design might not lend itself to that much
> performance optimizations, and would be tramped by a factor of 2 or 3 by 
> something that works differently.

I'm totally open to changing cairo's implementation as much as
necessary to achieve good performance. What's not open for change is
the user-level API semantics and the "high-quality" guarantees. But I
haven't yet seen any evidence of either of those putting any roadblock
in the way of performance.

> Also, I don't know how Xara LX achieves its high-quality high-throughput 
> results, but I would be
> surprised if this involved any tessellation. Hope to see that code
> soon.

I've talked to the Xara folks about this some. I know it's a "scanline
renderer" which yes, I assume means no tessellation. It was originally
written in assembly language, which has been since ported to C,
(though very assembly-like C obviously). I'm hoping to see the code
soon too, but I don't expect to find much very readable. ;-)

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