36: ten times better than Firefox 3.6

"But ours goes to eleven."

This post is being typed in Firefox 36, which is, of course, ten times better than Firefox 3.6. Jokes aside, there are some noticible improvements, particularly in the build process; the new unified build (which glues certain blocks of code together into single megafiles) compiles nearly 20% faster on this G5. Linking the big XUL superlibrary, instead of over 15 minutes of drumming my fingers on the desk while the CPU gets pegged, is now just four or five minutes due to the reduced number of files and probably even less on an opt build because it has even less code to go through. Unified builds also enable the compiler to do better optimization between files, so even this debugging build of Firefox 36 aurora feels pretty tight. Cumulatively, these improvements make me very optimistic for 38ESR, our next (last?) major version, and make maintenance much less onerous. The recently added in-content preferences, while another carbon copy of Chrome chrome, do work pretty well and integrate nicely into the browser. Helpfully, Aurora now uses a totally separate profile from the production Firefox/TenFourFox by default; previously I had to run tandem profiles by hand.

36 does have its problems. This is a "Developer Edition" build; Mozilla is trying to get developers to move into earlier testing tiers, so they've hung new black duds on the browser chrome which look hideous on Tiger. Since we don't release Aurora builds routinely, I'm just not going to support this livery; I have enough problems with the default theme without that. New tabs kept crashing until I figured out that Electrolysis was getting activated by the page snapshot feature (we won't support this either; our tabs will default to blank in 38). Also, JavaScript performance seems to have regressed some as Mozilla makes BaselineCompiler more of a gatherer for better IonMonkey optimization than a decent compiler in its own right, but my aim is to have Ion ready for 38, so there.

Big-endian builds got hit by bug 1105087 which was fallout from inadvertently requiring Skia for graphics drawing on our platforms which don't yet support it (software drawing is sort of a mess in Firefox these days). Skia allegedly has big-endian support now, but it doesn't have a big-endian pixel order in common with Cairo which usually does the software work, so even just turning it on doesn't fix the problem. The proposal Mozilla made was to write some more code in there to do byteswapping when graphics cross between drawing modules, but that means four byteswaps for this sort of operation, and that totally sucks. 36 just has bug 1097776 backed out because Skia still has issues on 10.4 and we don't really need it (I prefer quicker if less clean output anyway), so we'll see if Mozilla will accept my counterproposal of two separate codepaths. If they don't, I don't know what the plan will be for Linux and *BSD.

Once I have 36 to the point where I'm basically happy, I will release changesets and continue with the Ion work; I am not planning an unstable build until 38 beta and it is likely that 31 will not be discontinued until 38.0.1 or 38.0.2 to allow enough testing cycles on IonPower. IonPower seems like a cool name for our new backend. I just came up with it. Like it? Yeah, it's awesome.

The general consensus on the speculative changes in 31.3.1pre is that JavaScript without background finalization is better and movie performance with more aggressive buffering is a wash. However, all of my test systems here play WebM somewhat to substantially better with the video buffering change, so I'm going to keep it and see what happens with wider release. Besides those changes, reductions in tab/window undo and the hyphenation bug fix, I've also been discovering other potential glitches in PPCBC during the IonPower rewrite and these will also be fixed in the next version. 31.4 is scheduled for release on 13 January.

Happy New Year, everybody.