TenFourFox 19 beta: Judgment Day

COMING TO A POWER MAC NEAR YOU
RATED PG-19 FOR A PRETTY GOOD PORT OF 19 BETA

Yes, it's Judgment Day, and we've been judged absolutely righteous. Mozillanet has exterminated all 10.4 and 10.5 computers from the earth web, but the resistance has sent their computers forward in time with the use of advanced compiler technology to save 21st-century humanity from Intel-based hunter killers and Tim Cook drones. Excuse me, there's a police officer at the front door who bears a strange resemblance to Robert Patrick. I'll be back.

And I'm out of desperate Terminator jokes, so here's TenFourFox 19. Our personal "judgment day" was the end of 10.5 support in Firefox, officially in 16 (but 10.5 code was kept by arrangement in 17 so we could reenable it in the ESR), and the need to upgrade our compiler toolchain to a later gcc/bintools due to unacceptable hacks needed to get gcc 4.0.1 to work. Our compiler adventures were already excessively documented in this august publication, and the rest of the work was upgrading our build system to handle the new compiler and build independent binaries, and lastly finding and restoring the code Mozilla deleted or changed for the new 10.6 baseline. So now you have it in front of you to try.

This port was the opportunity to pay off much of our accumulated technical debt. The compiler upgrade alone allows us access to better PowerPC code generation and optimizations, and it also allowed me to jettison many of the gcc 4.0.1 compiler hacks that hampered portability. Because of improvements in the standard libraries also available in gcc 4.6.3, we now carry our own copies of libgcc and libstdc++ instead of using the system ones and the internal js, firefox, XUL and dylibs are all linked against it to make a self-contained package. Tobias already worked out most of this for AuroraFox, which uses a later gcc as well, although it required some tweaking for current MacPorts and 10.4. However, binaries are not significantly larger since the new linker we are using is also more efficient. My original fears about memory bloat do not appear to have been realized, either, so we are probably still okay with a 512MB RAM supported minimum. (Users at this minimum should test and report in.) Builders should note that our HowToBuildNow document now has a new section for our 19+ releases.

The new hotness has been pretty thoroughly tested on both G4 arches and G5 on 10.4, but I don't have any G3 systems running 10.4 currently, and I don't run 10.5. Leopard users and G3 users, I am particularly interested in feedback.

The biggest change between 17 and 19 is the introduction of what Mozilla refers to as "display-list based invalidation," or DLBI. Introduced first in 18, it is a deceptively simple optimization that forces the layout engine to be more exacting about what it needs to have redrawn in an effort to reduce pushing unnecessary pixels around. DLBI does not make things faster, per se (and there are some edge cases where it will make performance worse), but it does make things smoother. As an example, compare my favourite even-handed American politics site, RealClear Politics, in 17.0.2 and 19b1. After you've vomited reading articles opposed to your personal views, at the top right is a marquee with arrows to go right and left. Try scrolling through them. It's not necessarily faster, but it looks a lot nicer. Another site that shows better animation is one that had me chagrined in 17, local radio station KFI AM 640. On some sites, this almost completely erases the performance loss from the layers change introduced way back between Fx3.6 and Fx4. Because we are nearly entirely rendered in software, anything that involves pushing less pixels means better performance and better animation. DLBI is that.

A large change like DLBI also means massive regression risk. In 18, Mozilla fixed quite a few of these and I expect many more. If you find a rendering difference between 19 and 17.0.2 on a site, it is imperative you do a test on a Tier 1 official Firefox build (with hardware acceleration off) to see if it occurs there too. If it does, report it to Mozilla; it's not our bug. I am sure we will have lots of regressions unrelated to this, so I really want people to not clog up the worklist with upstream problems. Remember, please do not file issues on unstable builds on Tenderapp to avoid confusing regular end users on the stable branch. And before you ask, it is not possible to backport DLBI to 17. Sorry.

19's most ballyhooed change, however, is disabled in our build: the JavaScript PDF viewer. PDF.js actually has been part of Firefox for some time, but this is the first time it is being user-exposed by default. However, it's a poorer renderer than Preview.app or (natch) Adobe Acrobat, it's a much slower renderer (its speed is at best tolerable on this quad G5), and there's some argument from security guyz on whether it's even a safer renderer. PDF rendering is going to be the next frontier for Power Mac porting, and I'm looking at updating Vindaloo to see if this can be a future means to safely handle PDF files on PowerPC, but that's another story (and it won't be integrated with the browser in any case). You can go into about:config and turn the JavaScript PDF viewer back on, and some of you already have, but I have no plans to ship that as default until the speed improves.

18 and 19 also offer rudimentary WebRTC. I need to explore this more to see if it's feasible to use on Power Macs, but given that our AltiVec WebM is really only an option for high-end G4s and G5s and we don't have any AltiVec code of any sort in WebRTC, I don't have a lot of confidence that it's going to be worth porting. Right now, it is turned off at the compiler level.

Locally, we also have some improvements of our own specific to PowerPC OS X. In addition to the same faster font enumeration code added to 17.0.2, our version of 19 also offers AltiVec-accelerated blurring and shadowing thanks to Tobias' work in issue 189. This further improves display and scrolling performance especially on pages that blur or box-shadow the entire background, requiring the CPU to do a lot more compositing work. Don't worry, G3 owners; you may not have AltiVec, but you do have a better C-language version handling the blurring/shadows for you too.

For QTE users, the QTE didn't seem to work right with 19 aurora, but seems to be okay with 19 beta (though with some errors in the console). I'm tracking this closely for now.

The biggest announcement of all, however, is that Firefox 19 is now being offered to Android handset owners with ARMv6 CPUs as "slow" as 600MHz with as "little" as 512MB of RAM. Read that carefully. Does that remind you of any particular systems on some other RISC-based platform abandoned by its manufacturer? The fact that Mozilla is now concentrating on lower-spec devices (not just for Boot2Gecko but for flagship Firefox Android) means that they will be continuing to audit for and seek performance wins in Gecko, and a lot of this will be in cross-platform code that will in turn improve performance in desktop Firefox and in TenFourFox. And that, as they say, is a Good Sign.

The T-1000 has turned itself into my cat and is busily reprogramming my security system, so you'd better get the build from the Downloads tab (and read the Release Notes) while you still can. Hasta la vista, baby.