« March 2006 | Main | December 2006 »
April 25, 2006
"Why so big?"
One question that people have about our implementation is why we use so much memory. Robert O'Callahan had one opinion regarding this, and we are indeed fixing some of those issue. Recently while changing how path data was stored, I ran a torture case through the valgrind massif heap profiler and came up with some interesting data.
The testcase in question is the Renesis plan.svg, a 30MB SVG file that they use for demoing their implementation. They can load it in about 6-7 seconds and use about 50MB. A debug mozilla build takes about 1:50 and about 267MB. Looking at what plan.svg contains, it breaks down like this:
| Element | Count |
|---|---|
| defs | 1 |
| ellipse | 10051 |
| text | 1719 |
| a | 1 |
| tspan | 48 |
| use | 96 |
| polygon | 4 |
| path | 157944 |
| pattern | 1 |
| rect | 1 |
| g | 117193 |
| svg | 1 |
The output of running this through massif (with annotations added by me) is as follows. This is on a build with the path data storage change from bug 334999 - a trunk build would probably have the small objects used for path storage grouped into "other". The associated html output file is available here.
As you can see, it seems that the largest memory user is strings and associated data for generic attribute storage. However the 60MB+ it uses seems excessive for a 30MB file. Not sure what's happening here - opinions of gecko experts welcome.
Losing about 25MB for malloc control overhead seems like a serious problem, if that number is indeed correct for the glibc allocator. It suggests that we're allocating an excessive number of small objects. Some of this is likely from the unconverted SVG base types, but getting a better handle on what is causing this would be good.
SVG Frames take a considerable amount of memory, and is one of the things we're actively working on cutting down, so we can ignore that for purposes of evaluating the graph for now.
Elements take a fair amount of space. Some reduction could be done using properties for infrequently used fields.
Posted by tor at 7:18 PM | Comments (5)
April 5, 2006
"Why Cairo?"
It's a good question, and has been asked on gmane.comp.graphics.agg. Anti-Grain seems to be faster in informal testing (someone really needs a benchmarking framework to compare the numerous 2D oriented APIs), so someone was wondering why Mozilla chose to cairo as its rendering solution. Unfortunately the answers thus far haven't been that satisfying, and seem to fall into a number of categories:
- "C++ is bad." Anti-Grain is implemented in C++ with templates, but this seems like a tired argument at this point in time.
- "Cairo has a hardware acceleration story." Anti-Grain is a pure software engine, while cairo does have a OpenGL backend (called glitz). Unfortunately the owner of this backend, David Reveman, is currently being kept busy with Xgl development, so it is experiencing maintainer bandwidth problems.
- "Cairo has PDF/PS output." This seems to be the strongest argument in cairo's favor.
It seems that Mozilla chose to switch to cairo for all rendering to both gain graphics capabilities and to shed responsibility for writing platform specific graphics code, leaving the later in the hands of the cairo developers. Unfortunately on the second front it seems that Vlad and Stuart have had to become the owners of the OS-X and Win32 backends, so we haven't really gained much there. The core cairo developers work on linux, so that's the platform that gets all the attention.
While advanced graphics capabilities are there for the taking in cairo, using them tends to throw cairo off its fast paths. Normal webpage display (only translation transforms, pixel aligned objects) will remain on the fastpath, but once page zoom or svg content is introduced we're going to start hitting performance issue.
The major drawback of Anti-Grain is that it is a software solution, without a hardware acceleration story going forward (as far as I can tell -- corrections welcome). With graphics hardware becoming much more capable, even on mobile devices, this seems like a serious future limitation.
For completeness I should mention Xara and their software-only rendering kernel, which they claim is much faster than cairo. Inkscape also has an internal 2D rendering engine.
Looking at hardware accelerated 2D oriented APIs, I know of the aforementioned cairo with glitz backend, OpenVG, and Amanith. Cairo's glitz currently has a maintainer bandwidth problem and might be compromised by being a backend for a software/hardware bridging engine. OpenVG has an OpenGL-like API (and appears in at least some instances to have been implemented atop OpenGL ES) and is mainly being picked up by the mobile market. Amanith as 2D API implemented atop OpenGL, but rather than use the OpenVG API they've chosen to design their own C++ one.
For a library that's often touted as being the future of Linux graphics, it seems cairo needs a lot more development resources working on both the library and the X server capabilities it uses; or perhaps some thought should be given to more direct-to-OpenGL libraries.
Posted by tor at 7:16 PM | Comments (19)