Mozilla Cairo Vector Graphics Update
Sunday April 24th, 2005
Robert "roc" O'Callahan has posted an update on the work to move Mozilla's graphics infrastructure to Cairo. Formerly known as Xr or Xr/Xc, Cairo is a cross-platform open-source vector graphics library. According to roc, migrating to Cairo will "give us modern 2D graphics capabilities (such as filling, stroking and clipping to paths, general affine transforms, and ubiquitious support for alpha transparency)." Cairo can send its output to a number of different backends, making it suitable for producing graphics for both screen and print. By utilising the Glitz library, Cairo can draw hardware-accelerated graphics with OpenGL, allowing Mozilla to take advantage of modern 3D display hardware.
In his weblog post, roc includes a screenshot of a Linux Mozilla Application Suite build using Cairo to render webpages and its XUL user interface. Performance needs work though: "Right now," roc says, "the speed is best described as somewhere between 'glacial' and 'proton decay'." Eventually, Cairo should make rendering webpages significantly faster for users with modern 3D hardware (the vast majority) and about the same as it is today for everybody else.
As it's cross-platform, Cairo will remove the need for lots of platform-specific graphics code and it will also provide a single "rendering pipeline" for all displayed content. Cairo has particular advantages for the recently checked-in canvas element and Mozilla's native Scalable Vector Graphics implementation. The multitude of Cairo backends should also make it simple to implement features like converting a webpage to a PDF file or saving a document as a PNG image.
The Mozilla2:GFXEvolution wiki page has more details about the plans for moving towards Cairo. The Cairo code will be wrapped in a set of thin C++ wrappers known as Thebes to make it easier to use. The Mozilla team will also be making significant contributions to the Cairo project itself. Last year, Cairo was relicensed under the Mozilla Public License (in addition to the LGPL), removing any license compatibility problems. Mozilla isn't the only backer of Cairo either: the GTK+ toolkit (used by GNOME) is moving towards Cairo as well.
Check this with Rasterman, authour of Enlightenment. One of the delays of E17 (as I beleive) was precisely wish to adopt new rendering primitives, supported by 3D/2D modern hardware. The end result was quite disappointing, showing that hardware has way to high latencies to make any sense for casual GUI drawing.
Obviously Rasterman did the research from POV of window management, but still IMHO workloads are quite similar.
Unless you have hundreds textured surfaces with bunch of effects applied, hardware rendering make not much sense.
#6 Re: Check this with Rasterman
by roc <firstname.lastname@example.org>
Monday April 25th, 2005 2:22 AM
Are you talking about this? <http://developers.slashdo…189&tid=104&tid=8> That doesn't say much other than "NVIDIA's XRender was poorly optimized".
The fact that games draw massively complex scenes at high frame rates suggests to me that OpenGL performance will be adequate. First-person shooters demand significantly lower rendering latency than your average Web page...
I think there might be some confusion on this issue. The problem you are referring to occurs when you use an OpenGL renderer, but the card/driver doesn't have native OpenGL support. In that case, the Open GL operations are performed in software. Thus hardware rendering becomes slower than software rendering, because of the overhead of 2d abstracted hardware on top of 3d software rendering.
If the hardware has a decent OpenGL implementation it will be vastly more efficient than software rendering. Here's a relevant link in the enlightenment FAQ: <http://www.enlightenment.…mp;select=ePortal#GLaccel>
Seeing how experimental all this is, is it still too early to file bugs, or should we do them anyway? Asking because some of the bugs look rather obvious (like bad color ordering on Win32 where it should be BGR), so I'm assuming they know about it... But it's exciting to look at anyway :D
Cairo itself does look like an interesting way for Mozilla to go; nice to see that Mozilla is essentially getting outside help to do interesting stuff with graphics (and I'm sure they'll get a boost from the Mozilla folks too). That, and possibly accelerated drawing is cool :) Better image scaling, maybe? Hopefully they won't need to worry about keeping the API too stable (as far as I know, they're still messing with the API and havn't finalized it yet).
So now we get even more of a race between Mozilla/Cairo and IE/Avalon :p
#7 Re: Is it too early to file bugs?
by roc <email@example.com>
Monday April 25th, 2005 2:24 AM
You can file bugs as long as you're willing to fix them :-)
Better image scaling is definitely on the agenda.
#14 Re: Re: Is it too early to file bugs?
Monday April 25th, 2005 8:12 AM
Thank God. That's my biggest pet peeve with most browsers -- linear scaling.
So with this Cairo, new features like anti-aliased and dotted/dashed rounded borders, rgba() colour values, text-shadow, etc. will be more likely to happen in the near future? That’s great :).
Oh, and let’s not forget: pretty image scaling instead of the current linear method :).
Yes. rgba() might already work, I just have to test it. Antialiasing is already active everywhere; I will actually need to *disable* it in some places to avoid problems. text-shadow's a little more work to implement but it will be much easier now. Better image scaling should be easy to do although we'll probably only enable it for those with hardware acceleration.
Will this also mean, that Mozilla will *at last* get good printing capabilities (also for non-latin languages)?
Cairo itself still needs a lot of work on the printing side. For the immediate future we might have to stick with our existing printing backend. But there are Cairo people working on PDF output for Cairo and once that's in good shape, we'll be able to use it to get nice PDF output, and then we can use an off the shelf PDF to PS solution (perhaps one that's built into your system, if available) to print that.
Robert -- you describe the performance now as pretty glacial. What are the issues behind this performance at this point? Where are the bottlenecks?
I'd also like to know how big Cairo is, compared to all the Mozilla code it'll replace. I won't start complaining about 'bloat', since its clear that using Cairo will save a lot of work over the long term.
Emphasis so far in Cairo has been on getting the functionality working, not on getting it working efficiently. As far as I can tell there are no real bottlenecks -- just a whole lot of unoptimized code that nevertheless does what it's supposed to do.
#15 Better Image Scaling == Page Zooming?
Monday April 25th, 2005 1:24 PM
I take it to mean (from what I've read in previous comments) that once Cairo is ready to be turned on by default that better image scaling will be implimented. Would this also mean that Page Zooming (a la Opera) would be implemented?
From my memory, the bug comments relating to page zoom pointed out poor image scaling as the main hindrance to implementation.
#16 Re: Better Image Scaling == Page Zooming?
Monday April 25th, 2005 2:12 PM
Page zooming depends on the units code being rewritten.
ROC said it's expected to land in 1.9.
The zoom bug is : <https://bugzilla.mozilla.org/show_bug.cgi?id=4821>
But dbaron does say in that bug that cairo will make page zooming easier to implement.
I can't wait to see this up and working. Does this mean that if I have an OpenGL supporting GFX card, that rendering any painting operations (autoscrolling for instance!) will be much faster? I would love to see the day when transparent, fixed images don't max out my CPU to 100%, but pass on the work to my GFX card. It might not scroll slower than a dead snail then...
Also, Cairo natively supports cross platform, cross OS, so that's good for Mozilla's sometimes erratic ifdef coding.
#18 Re: Can't Wait!
by roc <firstname.lastname@example.org>
Monday April 25th, 2005 4:15 PM
Transparent fixed images are exactly the sort of thing that will see a huge speedup from hardware acceleration.
Hope this improves dhtml performance in the future. You could use mozilla to develop simple games. cool.
#20 full potential of canvas element
Tuesday April 26th, 2005 7:50 AM
Will the canas element be available in Thunderbird? Would it be possible to use it to allow you to directly draw things into emails?