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.