I and a few others have been poking at our widget layer for the past few weeks, looking at adding Qt support.  There was an earlier attempt at a Qt backend, but it never really got maintained, and there wasn't much interest in it back then.  Recently, though, Qt has made great strides on embedded devices and with support for advanced graphics architectures (such as support for OpenGL and DirectX rendering), and might be a great way for us to get a feel for some of the problems we'll face in the future when we try to integrate 3D-accelerated rendering into Gecko.  Folks at Nokia have contributed much of this code, since they're interested in experimenting with Qt as well.  We've got the initial work available on a hg branch (off mozilla-central; our first experiment on big-project branches in the future hg world).

I've had a great time working with Qt so far; it seems like a well-designed modern toolkit.  There are a few quirks; most notably, the pieces that Gecko/Cairo needs to render text aren't really there, but on the whole the integration is pretty good.  The big text piece that's missing is a drawGlyphs method on QPainter — something that would take a QFont and an array of glyphs and positions.  Additionally, methods to go from a string to an array of glyph indices/positions for a given QFont would also be helpful (though most of our font backend here is using FreeType directly, so we can obtain glyph indices directly).  In the QPainter Cairo backend that I wrote, I kind of cheat on this issue under X11 — I grab the X Drawable and pass on the show_glyphs work down to a wrapper xlib surface... but that doesn't work for Qt Embedded.  Anyone out there who knows Qt innards well want to implement this?

There are a few other minor annoyances with QPainter; Cairo's rendering code does a pretty good job of letting operations be specified in a general way (e.g. everything with paths), and it does whatever optimizations are possible internally (e.g. converting a rectangular path to a rectangle for clipping/painting purposes).  QPainter doesn't seem to have these optimizations for the general path methods, so the QPainter backend has to do a bunch of extra work to detect this case to call the faster filling functions.  Similar optimizations are missed for brushes — filling with a tiled pixmap QBrush is slower than calling drawTiledPixamp, even without transforms.  The Cairo backend tries to handle these cases, but there's more that needs to be done.

Overall, though, what's on the Qt branch now works pretty well under X11; under Qt Embedded, there are some problems with text rendering mentioned above, but things are in good shape otherwise.  I hope that in the future that the Qt port will be a toplevel supported Gecko port, alongside gtk2, Win32, and OSX, but there's still a bunch of work needed to make that happen.  If anyone's interested in helping out, drop in to #gfx on mozilla irc!

(Note that there aren't any plans on switching away from gtk2 for our official Linux/X11 builds; gtk2 will remain the default supported toolkit there.)

More to come on Canvas 3D in a bit, but I wanted to post that I've (finally!) updated the Canvas 3D extension to work with the latest Firefox 3 betas — will work with the latest nightlies, and should work with 3.0b5 as well.  You can grab it from its new home at addons.mozilla.org, which will give me the ability to push updates in the usual addon update fashion.  In the next week I'm going to try to provide builds that can use pure software rendering through Mesa 3D, for those without working GL support.  (The previous post on Canvas3D has some more information and a few test examples.)

I've tested this build on OS X and Windows; I was unable to test in Linux under VMware — Firefox crashed with a GLXUnsupportedPrivateRequest X error.  (If anyone wants to check this under Linux with a real OpenGL driver, let me know how it goes.)

As a former Windows user on my MBP, I had half of my 160gb disk allocated to Windows and the other half to MacOS X.  This worked fine for quite a while, but now that I have a 30GB Linux VM on my Mac partition, things started getting tight very quickly.  I was terrified: I had to shrink my NTFS Boot Camp partition, then move it, and then expand my MacOS HFS+ partition.  In the past, this type of thing almost always resulted in recovering from backups.

Looking around, though, I found iPartition, which claimed it could do exactly what I wanted.  So, I bought it, burned the CD.. went through the cute UI (grabbing a little circular slider and adjusting partition sizes while large numeric readouts adjust in real time), gulped, and hit Go.

An hour or two later, everything was resized, moved, and back in action.  I'm impressed (which is why I'm posting... usually these stories don't have happy endings).  The software's a bit pricy for something that you won't use all that often (I wish they'd included a full version of iDefrag along with it), but that's probably exactly why it's pricy -- when you need it, it does exactly what you want.

There were a few things that I left out of my previous post about Cairo status (as a few people pointed out), and I wanted to highlight them here.

For the past two months, Antoine Azar and Frédéric Plourde have been working for Mozilla, cranking away at both Cairo and pixman.  They started out with a completely unfamiliar codebase and quickly producing useful enhancements.  Antoine was able to implement some missing support in pixman, allowing us to implement smooth scaling of images.  This was the final missing piece that makes Firefox 3's full-page zoom feature able to display a high quality version of the unscaled page.

Johnathan sent me some screenshots from Vista, comparing the rendering of a recent Firefox 3 beta to IE 8's beta.  He's running in Vista's high-DPI mode, so all the scaling was applied by default.  Firefox is on the left, IE's on the right... the difference is pretty striking (click for the full image, make sure you view it unscaled for all the gory details):

Linux users will have to wait a little longer to get higher quality image scaling; as we now rely on the X server to do image compositing through the Render extension, we'll have to wait until the pixman patches are integrated into the X server.  I'm hoping that will happen in time for the next X.org release.

Frédéric has also been working with pixman, specifically low-level optimization of the compositing routines (pixman is used on Windows for all non-trivial rendering, and used indirectly on Linux through the X server).  He cleaned up the existing MMX code so that it could build with Visual C++, and is now working on further optimization and extending the existing fast paths.  In Mozilla, we've enabled the MMX code everywhere.

At around the same time,  a rapidly-progressing effort to add SSE2-optimized paths to pixman began on the Cairo mailing list, and Frederic will be joining those guys shortly.  Given that most x86 computers in the past few years have full SSE2 support, it makes sense to focus work there. Early results are showing significant peformance gains, which should be a huge boon for authors taking advantage of SVG and Canvas features.  Much of this additional work will not ship with Firefox 3 at release time, but it may come shortly after in a minor release.  I'm pretty excited to have additional improvements already waiting in the wings... I think you'll see Gecko continuing the past few months' trend of rapid development even after Firefox 3's release.

One of the things that I've worked on for the past while is a Quartz backend for Cairo -- mainly for Mozilla, but also to show that Cairo has a great API that maps well to existing 2D APIs.  Cairo is a great 2D portability layer, ensuring that rich 2D graphics can be portable.  I'm excited about the upcoming Cairo 1.6 in particular, because the Quartz backend will be marked as stable and supported.  This will mean that Cairo is usable and supported on the three main platforms in use today -- Windows, Linux, and MacOS X.  I've filed a bug with Apple (bug #5802204) about making public the APIs that I've had to use to implement the full suite of Cairo capabilities using Quartz.  (For anyone interested, the cairo-quartz implementation file has a handful of quite useful methods.)

One interesting bit of fallout from this is that Quartz/CoreGraphics also happens to be the native graphics layer for the iPhone: so, Cairo is trivially portable to the iPhone.  The major issue is that Cairo currently uses ATSUI for font access, whereas it needs to be using CGFont -- which is the native font API suppored under MacOS X 10.5 and the iPhone.  (However, the CGFont API is missing many public methods to make it entirely general, but I hope that will be remedied in time.)  I've made some last-minute changes to Cairo to allow us to switch to a CGFont-based text backend with no change to Cairo-using apps, and I have such a backend in progress for landing shortly after Cairo 1.6 is released.

There is also some exciting work going on with improving the pixman library that cairo uses for its software-only rendering -- I've often maligned it for being slow and hard to work with, but the newer cleaned-up version is much easier to deal with, and Soeren has great plans for its future.  A number of people are working on adding highly optimized MMX and SSE2 compositing routines to augment the little bit of MMX code that's present currently.  Initial benchmarks are pretty encouraging, and I'm hoping that we can do some optimization work targetted at ARM as well.  There is also some work in progress to implement accelerated backends using OpenGL (and ultimately Direct3D).

Gecko 1.9 (and thus Firefox 3) will be shipping with Cairo 1.6 (or, as close as possible, if the schedules don't quite line up): everything that Firefox 3 renders on the screen is going through Cairo, and is ultimately translated by Cairo into the native platform API.  Future work to expand Gecko's graphical capabilities will intimately involve Cairo.  It's safe to say that Cairo is ready for prime time.