28 Jul 2005 (updated 28 Jul 2005 at 16:32 UTC)
»
Cairo tutorial at OLS
On Friday, Carl Worth gave a Cairo tutorial. He went through the Cairo
API and explained what each function did, and we played with several
example files to see how to draw shapes, write text, and so on. He
showed how the same code could be used for drawing to the screen as well
as to generating postscript output. The tutorial plus the required
dependencies are posted here:
http://cairographics.org/snapshots/
It was a very enjoyable tutorial. I learned a ton and found it quite
inspiring. After the tutorial I browsed through the Inkscape codebase
and got a little bit of an idea on where Cairo would plug in, and what
sorts of changes would be needed to get us there. Migrating to Cairo
looks like a lot of work, but it also sounds like it'll be quite fun.
Cairo is still in heavy development, and the focus to date has been on
getting correct results moreso than optimization. I got a copy of
ScislaC's Gaze SVG image for use as a stress case, and Carl and I tested
cairo on it, and compared its rendering and performance with Inkscape.
Cairo rendered the file badly, making ScislaC's fairie look like some
undead creature. Carl found out that this was caused by a small bug in
Cairo, which he's now fixed, and the image renders well. Carl measured
that it took 48 seconds to render this with Cairo, compared with around
a second or so by Inkscape. Carl will be able to use this file as a
performance test case, with the objective of getting the performance
down within range of Inkscape. He feels confident that between liboil
and some profiling, this should be very doable.
I don't know if there has been very extensive comparisons of livarot and
cairo, but my own tests and the informal testing I've seen others do
seems to indicate that cairo is pretty close to livarot in terms of
rendering functionality, however I'd want to see much more testing
before we can say for sure. I'm confident that if any differences do
emerge, and if cairo is found to be incorrect, the issues are going to
get fixed swiftly. I don't think Cairo would be a drop-in replacement
for livarot; I think there is additional code that livarot (and libnr)
has that is out of scope for Cairo, that we'd need to repackage somehow
and use, but it will take some investigation to identify what these
things would be specifically.
The big news at the conference was the integration of GNOME/librsvg and
cairo. Several people were experimenting with use of cairo for
rendering the desktop widgets and such. Currently, it appears that
Cairo development is heavily focused on supporting these efforts.
Thus, Cairo seems to have reached a point where it is a viable
replacement for the libart-based rendering code in librsvg, and work is
progressing with that goal in mind.
However, note that the librsvg SVG backend that is under development
isn't precisely what we'd need for Inkscape. The 'r' in rsvg implies
that it's designed for single-pass-through rendering such as is needed
for static SVG displays as you'd need for widgets and desktop stuff.
Since Inkscape is an editor, what we need is a 'dynamic' SVG renderer,
that allows us to interactively alter the drawing as the user moves
things around, adds new drawing elements, updates style definitions, and
so forth.
The good news is that Cairo itself is designed as a dynamic drawing
library. It does not hold state on the items being drawn, and depends
on higher level code to track the drawing elements. Thus, what we'd
need to do is establish something like Inkscape's Repr and shape
hierarchy, but have it render by making cairo calls instead of
libnr/livarot calls. I think this will touch a LOT of the Inkscape
code, but on the plus side by replacing the rendering code it should
really cut down the amount of code we will have to maintain inside
Inkscape.
