On Thu, Jul 21, 2005 at 10:44:49AM -0600, John Taber wrote:
Jon and Bryce, When you get a chance on your return from the conference, could you post a quick recap of status and future of the progress Carl Worth and Keith Packard are making on the Cairo SVG backend ? Is it now as good as the livarot/Inkscape renderer or as librsvg ? And speed? Thks.
Here's a recap of the Inkscape, OCAL, and Cairo talks at DDC and OLS. I'll probably miss some important bits so I'd appreciate it if Rejon or anyone else that attended could fill in any holes.
Most of the presentations at DDC were about Xorg internals, which oddly didn't have many visuals. There were some presentations on libraries, and a few applications. The conference ran for two days.
My talk was in three parts: A presentation (using inkview), a live demo of inkscape, and a slideshow displaying some of the artwork that people have done. I've posted my files here:
http://www.bryceharrington.com/Present_desktopcon/
I think my talk went fairly well. I briefly explained what SVG is (I suspect most of them already know what SVG is), then explained where Inkscape came from (Gill and Sodipodi), and gave a quick rundown of a few of Inkscape's features (I borrowed Ted's SCALE slides for this).
Next, I did a demo of the new features in Inkscape, showing off the basic shape editing, all the new text capabilities, node editing, patterns, clones, booleans, and so forth.
I showed a few of the about screen submissions and a collection of Inkscape art I got from DeviantArt. I think people really liked this part of the talk. :-)
Finally, I explained some of the issues we've noticed among the community, such as the need for better SVG support in OOo, better PDF export from Inkscape (Keith Packard and Carl Worth were quick to shout out 'switch to cairo!'), and some of the rendering issues that librsvg users were finding. I also listed some of the near/mid term objectives from our roadmap, including the work that the SoC students are doing and some of the other projects that are on our wishlists.
There were a few questions from the audience. One person asked if by "full SVG support" we really meant full SVG support, including Javascript and animation; the answer was yes, full SVG support is Inkscape's primary objective. We already have the ECMA interpreter in the codebase, but need to do some DOM work to allow us to hook this up fully. Animation is probably further out, but definitely something we intend to add in at some point. There was a question I didn't quite understand about file sizes efficiency between SVG and raster; Pat Suwalski answered the guy's question. I also tried to explain that vector and raster image formats are really for different purposes, not really alternatives as much as different ways of representing artwork.
Jon Phillips had the last presentation of the day, and I could see that people were really tired and mostly had their heads buried in their laptops. However, I quickly saw that Jon is a *damn* good presenter and gave probably the best presentation of the whole conference. He cajoled the audience out of their laptops joking about all the "dry Xorg talk" and that the OCAL talk would be light and easy. By the end of the talk I don't think there was a single person looking at their laptops!
Jon explained about how the Open Clip Art Library is all about building up a community resource of graphics. The origin of the library was with the Sodipodi Flags Collection that Uraeus ran, and that directly inspired the project. Jon explained the philosophies of Creative Commons and Public Domain, and discussed with the audience about why the commercial clipart packages can be problematic, and about what Public Domain meant and why for clipart it is so important. People seemed to fundamentally grasp the importance of the project and I saw a lot of people nodding with the points Jon was making.
One person asked if there were copies of international symbols, and Jon showed that there were quite a few. Someone else asked about icons, which Jon showed. There was some talk about interfacing to the library, DMS, and other projects that allow for viewing of the images.
In addition to Inkscape and Open Clip Art, there were several talks on Cairo of relevance to us. Carl Worth gave a presentation that focused on the life cycle of a bezier curve, explaining how the points in the curve and the stroke width are defined, how the renderer renders this information, and the types of flaws that can be found from various corner cases.
He demoed the issue in Inkscape by drawing a bezier curve and setting its stroke width extremely high, and then moving the end points around. The effect was that the end cap for the line got erratic, and occasionally 'spiked' outward. He explained that the cause for this behavior was that at such large sizes, floating point approximations became significant. The renderer was rounding point locations and placing corners such that it left "gaps" in the boundary of the line stroke; the filling algorithm thus essentially "leaked" through the gap, causing paint to extend beyond the end of the line, and other strange effects. (I'm sure I've totally butchered the description of this bug.) I don't think this is a huge issue for us because a) it only seems to occur when you set the stroke width to insanely high settings, and b) it'll presumably get fixed when we switch to cairo.
I also found the talk on liboil of relevance to us. liboil is David Schleer's "Optimization of Inline Loops" library, that packages a variety of assembly routines for performing low level mathematical operations, many of which are highly relevant to graphics programs. David is a lead developer on GSStreamer, which is the primary motivation for liboil, however there is also strong interest in seeing this library incorporated into Cairo to help jazz up Cairo's rendering performance. David requested that developers send in their assembly routines to be considered for inclusion in this library, so that all of us can benefit from sharing a common pool of code. I passed him a link to Inkscape's MMX code in libnr.
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.
One other point of interest was in Keith Packard's presentation on TWIN. TWIN is an extremely trimmed down version of X11 that runs on embedded devices. Apparently, the night before the talk he needed a logo, and Carl told him to "use Inkscape!" so Keith grabbed an image of the constellation Gemini off images.google.com, imported it into Inkscape, and manually traced out his logo no prob. Looked great, too. :-)
I was glad rejon and I were able to attend the conference. I'd definitely encourage other Inkscaper's to go to it next year, especially if they can present. I think this would be good place to present about development work you're doing on Inkscape. Also, demoing Inkscape was a lot of fun, and I'd strongly encourage others to demo it at other conferences if you get the chance.
Bryce