« textPath for Firefox 2 | Main | "Why so big?" »

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:

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 April 5, 2006 7:16 PM

Comments

Actually, heavy use of C++ templates has a tendency to not compile on some of our platforms unless very carefully tweaked....

Posted by: Boris at April 5, 2006 9:12 PM

Just curious, as I have no real experience with open source software - but if Cairo has maintainer bandwidth issues, doesn't the new usage by Mozilla bring it more to the public forefront, therefore generating more interest? And at that point isn't it possible (or even likely) that this new interest in the platform would translate into developers being interested in Cairo's development?

But remember, I have no idea what I'm talking about :)

Posted by: brooks at April 5, 2006 9:19 PM

Just wondering how much influence companies like Novell have in the decision making of Mozilla to choose cairo as the rendering solution.
It might not be all technical reasons, but also political/business reasons.

Cairo is very slow on windows, it's at least 50% slower than what was used before that.
I'm just hoping this gets fixed (along with countless other issues) before Firefox3 comes out.

Posted by: Martijn at April 5, 2006 11:03 PM

> Just wondering how much influence companies like
> Novell have in the decision making of Mozilla to
> choose cairo as the rendering solution.
> It might not be all technical reasons, but also
> political/business reasons.
This really wasn't part of the decision process. We basically looked at what was out there (which was basically cairo and agg) and picked the one that we felt fit our needs better. I stand by our decision, although I kind of wish something better had been around then. I think cairo is slowly becoming that thing.

> Cairo is very slow on windows, it's at least 50%
> slower than what was used before that.
"Very slow"? Where are you getting your numbers? I'm running cairo windows builds daily and there are a couple things thare are a lot slower, but most are not noticable. If you're looking at Tp, there is a bug effecting Tp much more than it should. Tr/Tgfx numbers are much closer and are more related to actual cairo rendering speed.


I'd also suggest reading my post here: http://article.gmane.org/gmane.comp.graphics.agg/2500

Posted by: Stuart Parmenter at April 6, 2006 12:15 AM

If Cairo is hardware accelerated, shouldn't Firefox be significantly faster than without it?

Posted by: wg at April 6, 2006 1:26 AM

> I'd also suggest reading my post here: http://article.gmane.org/gmane.comp.graphics.agg/2500

Or one level up to see cworth's mail to which stuart replied:

http://thread.gmane.org/gmane.comp.graphics.agg/2494/focus=2494

Posted by: Jonathan Watt at April 6, 2006 1:31 AM

Well, I see you already found the bug(s)
It's https://bugzilla.mozilla.org/show_bug.cgi?id=328367 and its dependancies.

That's an interesting post, thanks.

Posted by: Martijn at April 6, 2006 2:08 AM

Thanks tor and Stuart for the summary. I was one of the people that publicly asked this question.

I would love to see cairo development pick up some steam now that higher profile projects are using it. Is it happening? Are there blogs we should be listening to? I definitely want to see a hardware accelerated solution some time soon...

By the way, I have heard that OpenGL will be limited/constrained in some way in a Windows Vista environment. Has anyone looked into this to determine if and how it would impact a OGL backend to cairo?

Posted by: Jeff Schiller at April 6, 2006 2:22 AM

Jeff, people that it was going to be the case, but as vlad posted recently, it won't be. Also see:

http://www.opengl.org/news/permalink/windows_vista_to_support_opengl_icds_for_aeroglass_compositing_desktop/
http://blogs.msdn.com/kamvedbrat/archive/2006/02/22/537624.aspx

Posted by: Jonathan Watt at April 6, 2006 2:34 AM

> # "Cairo has PDF/PS output." This seems to be the strongest argument in cairo's favor.

but if I got it correctly, this won't be used for Windows. This this still true?

Posted by: at April 6, 2006 7:23 AM

Regarding Cario having PDF output, there is a bug to allow 'save page as' to save as PDF (in Firefox 3), but it's still marked as WONTFIX from the days before we were using Cairo and PDF output was then, justifiably, unfeasible.

https://bugzilla.mozilla.org/show_bug.cgi?id=162659

This would be a really great feature to have for Firefox 3... at the very least, can someone change the resolution?

Posted by: Ian at April 6, 2006 8:10 AM

Inkscape has its own render but there are ideas to switch to Cairo:

http://wiki.inkscape.org/wiki/index.php/Cairoification
http://wiki.inkscape.org/wiki/index.php/SubsystemRearchitecture

It's interesting to know if it's possible Anti-Grain to be used as backend in Cairo.

Posted by: Ognyan Kulev at April 6, 2006 1:44 PM

What's happening with the cairo development?

Posted by: Rade at April 7, 2006 8:58 AM

There was no intent to "shed responsibility", but there was definitely intent to share responsibility and take advantage of the work that had already gone into cairo and would go into it in the future. We knew all along that we would have to contribute to that work, and have in fact been trying to find resources to contribute *more*.

Saying PDF/PS support is the most compelling thing in cairo's favour seems pretty short-sighted. There is hardware acceleration available in cairo _today_, and we'll likely be seeing some of the benefits of it in Firefox 2. You don't need glitz to get those wins on Win32 (where GDI is hardware accelerated now, and will be even more so on Vista) or Mac (where Vlad has already shown hardware acceleration via a CoreGraphics back end), and even if we do decide to use glitz on Linux -- where the hardware acceleration story is still very much "to be continued" -- we're *still* better off starting with the current state of glitz than without it, IMO.

If those answers are not satisfactory, what should we have done instead? Written our own modern 2D API and back-end architecture and then implemented it? I don't recall anyone, from the SVG community or otherwise, proposing a credible alternative to cairo, or even doing so now with the benefit of hindsight.

(Our interest in cairo predates Red Hat _or_ Novell investing in it to any degree, by my recollection.)

Who is saying that we shouldn't use a C++ library, though? Given that we're writing to a C++ wrapper API (thebes) in a C++ application, that would seem a pretty ridiculous position to take. I'd appreciate a pointer to that answer, as I can't find it in the thread referenced. Heavy use of templates can cause portability issues for us, but that's likely not the case here now that we've dropped VC6 support, and I hope will drop gcc 2.95.3 in short order.

I, too, wish that there were more resources being devoted to cairo, especially on the core of cairo itself (there is currently a fair bit of effort going into PS/PDF work, it seems), but I also wonder if the hours that were budgeted to be spent on SVG back-end improvements could make a meaningful difference in cairo's performance and capability.

Posted by: shaver at April 10, 2006 4:15 AM

Thank you very much for your answer, shaver!

Posted by: Rade at April 10, 2006 12:02 PM

It was my impression that the cairo and glitz had drifted apart as cairo development has progressed, and that glitz was in need of maintenance to get it working again.

Anti-Grain is an alternative that we knew about before the decision to go all cairo, but it was thought that the community was behind cairo and it would rapidly progress. While the linux community does seem to be behind using cairo (gtk2, etc), unfortunately few resources have been put behind cairo proper.

Why did I do a SVG rendering backend in cairo instead of Anti-Grain? At that time, early 2004, I don't think I had heard of the latter. After that, we were busy working on SVG features and didn't want to take the time to add yet another renderer and further complicate our maintenance problems (four renderer backends!).

I'm not arguing against C++, I was just listing the arguments seen in the referenced thread.

Posted by: tor at April 11, 2006 3:32 PM

The OpenGL acceleration is the future for the 2D vector graphic; I've just seen the video of amanithvg engine at http://www.amanithvg.com

Posted by: Reply at July 9, 2006 11:22 AM

5e4877876eaf Nice site http:/0zu.tw/ short url

Posted by: short url at December 20, 2006 11:20 AM

I have started a project to develop an ANSI C OpenVG implementation on top of OpenGL. It offers hardware-accelerated vector graphics but still remains lightweight compared to other C++ projects. It's hitting the first release sometimes soon:

http://ivanleben.blogspot.com/2007/07/shivavg-open-source-ansi-c-openvg.html

Posted by: Ivan Leben at July 8, 2007 9:49 AM