« Drowning in UI | Main | Please test your SVG with Firefox 3 Beta 3 »

November 12, 2007

Mozilla SVG speed and cairo

When using Mozilla SVG, you might have encountered cases where we are quite slow. While there have been great strides in fixing these in both the mozilla codebase and cairo between Firefox 1.5/2.0 and Firefox 3.0, we still see performance problems appearing.

When we profile these slow cases using tool like sysprof, cairo (or what it cause the X server to do in the case of unix/X11) usually makes up the majority of the time spent. If you're interested in helping with Mozilla SVG but don't feel like diving into the thick of Mozilla's flavor of C++, contributing to cairo would a great choice. It's a smaller, simpler codebase in straight C, has a responsive developer list, and improvements you make will help a large world of software beyond Mozilla.

Specific areas of interest to Mozilla SVG are:

Hit detection.
Currently, cairo_in_fill() and cairo_in_stroke() are implemented by tessellating the path and tests against the generated trapezoids. There are a number of other point in polygon testing methods which would be more efficient for implementing cairo_in_fill(). cairo_in_stroke() might be implementable by doing distance to line/curve tests for the path segments, along with some extra tests for the segment joins. Both of these hit detection functions are important to SVG as we are continually checking for objects underneath the pointer for event delivery. We do perform an early reject test against a cached bounding rectangle, but for complex geometry the time spent in cairo can become significant.
Track down overuse of *CompositeGeneral.
Many profiles we've run of slow SVG testcases show lots of cputime disappearing into this method, both on the client (named pixman_compositeGeneral or pixman_compsite_rect_general* depending on the version of cairo you're looking at) and in the copy inside the X server (fbCompositeGeneral). While ideally we'd like to avoid cairo's software renderer completely (as in Michael Dominic's work), it would be good to track down why rendering operations often end up there. My guess is that the frequent use of clipping in SVG (for inner <svg>, <image>, <marker>) is the cause of this.
Server side gradients.
Cairo does not use RENDER's gradients with the xlib backend. Since gradients are a frequently used SVG feature, speeding them up seems like a good thing to do, and if we can keep work on the server side it could be a win (might need work the server side to get the performance and fix possible problems with a currently unused server feature).
Extents.
Right now cairo implements extent calculation for both fill and stroke by tessellating the path in question. This is straightforward and allows cairo to reuse code needed for rendering, but it uses more memory and cpu time that is necessary for the query operation. SVG calculates the coverage information of an object each time a presentation attribute or property changes, so this can add up for complex geometry. Mozilla's SVG code can be changed in the post Firefox 3 world to work better with Gecko to avoid unnecessary calculations for changes that don't change geometry, but for now we need to assume the worst case.
Path extents.
This is a specification conformance issue rather than performance - the SVG IDL allows the bounding box of geometry (without stroke or mask effects) to be queried, and cairo_fill_extents() is both wasteful performance/memory-wise (see previous item) and doesn't give the answer we want for degenerate geometry.
Filters.
Mozilla SVG implements a full SVG pixel filter set (two of which, feImage and feDisplacementMap, unfortunately will not make Firefox 3) by hand as cairo has no native filters. It would nice to have filters in cairo; for the additional functionality it would provide to other users, the ability to hardware accelerate through OpenGL and pixel shaders, and to get more developers looking at speeding up the code.

If any of this sparks an interest, join the cairo mailing list and let people know. You'll be in touch with others working on cairo and get feedback on your ideas.

Posted by tor at November 12, 2007 11:41 PM

Comments

Great post! When SVG gets faster it will be soooo much fun to use!!

monk.e.boy

Posted by: monk.e.boy at November 13, 2007 10:42 AM

Did you see John Resig's SVG diagram of JavaScript,
http://ejohn.org/files/ecma-cloud.svg
? It killed my FF3!

Posted by: skierpage at November 16, 2007 5:22 AM