Thursday 15 January 2009
Post-3.1 Plans
While people are working hard to nail down layout bugs for the Firefox 3.1 release, there's also exciting work happening on the trunk for post-3.1.
- Benjamin Smedberg landed a big patch to make nsIFrame stop pretending to be reference-counted. It also replaces QueryInterface with a similar API called QueryFrame that doesn't need IIDs. This is a nice cleanup and simplification.
- Brian Birtles and Daniel Holbert have massively cleaned up and simplified the SMIL patch so that it's ready for landing. This is just the basic SMIL infrastructure --- considerably more work is required to implement all the features of SVG Animation --- but it's a great base to build on. SMIL support will be configured off by default; I think we should enable it when we've got enough implemented that we wouldn't feel embarrassed about shipping it.
- Robert Longson and Craig Topper have been doing a bunch of SVG cleanup. In particular, they've been removing a lot of the existing XPCOM-heavy datatypes for SVG values such as animateable strings and viewboxes in favour of lightweight objects that implement the SVG DOM interfaces via tearoffs. This lays the groundwork for making all these attributes actually animateable using SMIL.
- Fred Jendrzejewski has some patches that get rid of all our usage of deprecated types nsStringArray and nsCStringArray, in favour of nsTArray<nsString> and nsTArray<nsCString>, improving consistency with the rest of our code and significantly more efficient as a bonus!
- Jeremy Lea has a big patch ready to land that makes nsRect and nsIntRect be different types. It also separates nsPoint/nsIntPoint, nsSize/nsIntSize and nsMargin/nsIntMargin. This gives us some useful compile-time type checking to avoid mixing up integers (usually pixels) with our subpixel "app units" (1/60 of a CSS pixel).
- Boris Zbarsky has some nice changes for table-driven frame construction that shrink the code a lot and may eventually lead to performance wins.
- Jonathan Kew has implemented a Core Text backend so we can use that new API on Mac instead of ATSUI.
- Neil Deakin has a major focus rewrite in the works.
(There's more going on --- this is just what sprang to mind while I wrote the post.) We have more big architectural changes and features planned, which I'll talk about when they're further along.
For Gecko 1.9 (Firefox 3) we did a ton of architecture work, such as switching to cairo, and used most of our energy fixing bugs from those changes, so we didn't have much left to really exploit the new architecture. In Gecko 1.9.1 (Firefox 3.1) we were able to put in a lot of new engine features that were suddenly easy (e.g., text-shadow, border-image, SVG filters for HTML), but we didn't spend much time doing big architecture cleanups. I think that in Gecko 1.9.2 we're swinging back a bit to increase our investment in architectural improvements. But thanks to much better tests, and more developers, we should be able to keep the feature pipeline busy as well. I'm excited that we seem to have reached the point where we can get a lot of things done at once.
Comments
But I wonder what happened with a lot of the ambitious Mozilla 2 plans announced 2 years ago; I haven't seen any real update on them on planet mozilla. The switch the hg obviously happened. ActionMonkey apparently died and was replaced by TraceMonkey. And there's been efforts to deCOMtaminate and remove old data types and APIs here and there. But I haven't seen anything about automatically converting Gecko to standard C++, breaking API compatibility, or the big rewrites Brendan described. I suppose the automatic rewriting tools aren't mature enough yet, and in the mean time the developers are rewriting things more incrementally in a series of 1.9.* releases.