Beta Five is alive!

Thanks to Tobias' linker and work on the build system, I am now pleased to unveil TenFourFox 5 beta 1 (roughly Firefox 5 beta 3, although it is hard to assign numbers due to Mozilla's new release strategy, so I'm arbitrarily calling ours "1"). And now you will get to play with it.

Firefox 5 is pretty much the 3.6 to Firefox 4's 3.5 (speaking of, 3.5 is toast, so if you don't want to use TenFourFox at least use 3.6 or Camino), which is to say, it is the minor feature and bug fix update. Actually, there are at least a few marquee features worth pointing out despite the brief gestation, and the big one is CSS animation, which is something WebKit has supported for awhile and now Mozilla's getting into the act. This is the technology that I personally hope will nuke Flash for good. You can see some demonstrations of it, including this simple animated text page and, impressively, the Mad Men title sequence rendered in CSS3 (high end G4 strongly advised). Most of the rest is ticky stuff and spec compliance. The return of WebSockets, a custom interface for permissions, and other bits of challenging electronics will not appear until Firefox 6, which will hit beta in about three weeks.

We haven't sat on our butt for this one, however. Besides the work expended on porting the Firefox/Chromium IPC code to 10.4 (mostly by gutting it) and hacking on the build system (more on that in a moment), we have some new features of our own. First, JavaScript acceleration is now enabled for browser chrome. This means that the browser itself, a fair bit of which is written in JavaScript too, now gets fed into our exclusive PowerPC JIT tracer. The improvement is not nearly as dramatic because a lot of features the browser handles do not benefit from it as much as web pages do, but it still makes the browser quite a bit smoother.

Second, JavaScript typed arrays are now enabled in the accelerator. These are a recent addition to Firefox allowing fast native storage of data, and are an important part of the audio API and certain high-performance applications (and WebGL, even though we don't support it). Previously TenFourFox could not use the JIT for this type of code, which meant such applications trying to do for speed actually ended up running slower. Now they don't. This means smoother audio and faster overall performance for these specific kinds of applications (note that this doesn't affect benchmarks much since SunSpider and Dromaeo don't really test this).

Third, we are starting to add more AltiVec acceleration to the content chain, as promised. First out is AltiVec-powered scaling, which uses a SIMD routine to speed up filtering and scaling of images and video. This is in this build already. The next step is to accelerate YCbCr ("YUV") colour conversion, and then specific optimizations for libjpeg-turbo (we are using the unaccelerated version in TenFourFox 5, but this is already quite a bit quicker than the old library, so it's already a win). This might slip to "TenFourFox 6," but hopefully some of it will appear in 5.

Other changes specific to TenFourFox include expanding the stack even further (now Kraken can run, which crashes 4.0.2; this fix will also be in 4.0.3) and dialing back the loop filter for WebM videos a bit, which gains some marginal improvement. Unfortunately, HTML5 video is still mostly the domain of the G5 right now.

Oh, yes, plugins: the "P" word. Surprisingly, they still appear to function, but I haven't exhaustively tested them. Since we have some higher priority work to do rather than expend time and effort into something I already know will be unbelievably unpopular, I'll let you play with it and if their support and operation seems no worse, I will leave them alone for 5. However, some changes are in the pipeline for 6, so expect it then. Please note that they do not run out-of-process; the IPC code is gutted and they can't even if they were capable of it. Also do note that by the time Firefox 6 (and hopefully TenFourFox 6) come out around August, almost a year of no updates to PPC Flash will have elapsed. Imagine how full of security holes and crash bugs it oughta be by then. Just saying.

Let's also talk about what had to be done to get it to compile (builders pay attention). Tobias' ported linker from Xcode 3 is now required to function and is available for download from the Google Code project. Although it appears to be perfectly fine to replace your Xcode 2.5 linker with (and supports 32 and 64 bit in one executable), I prefer to keep my old linker(s) around, so there is a shim that comes with the changesets to install in place of /usr/bin/ld which lets you dynamically change which linker you use (handy for making libtool use a linker other than the default). For details on that, see README.ld for how to install the shim and the Xcode 3 linker, and how to get the build system to use it. I am rewriting the build notes and those should be ready in the wiki already. You do not need to install the linker just to run TenFourFox, by the way, only to compile it from source.

The reason the custom linker is needed is because Mozilla requires everything linked together into a big orca-fat superlibrary called XUL. This library roughly consumes around 750MB of space, and the regular Tiger linker can't cope even in 64 bit mode. In debug mode it is not stripped and remains this size, but is runnable in Tiger. In the optimized builds, it is stripped down to the typical ~25-30MB size.

Part of XUL (a/k/a libxul) is the IPC system, derived from Chromium (yes, that Chromium). Most of it will not build on 10.4, but we are fortunate in that Mozilla doesn't use most of it -- they use NSPR. Therefore, getting it to build was simply stubbing out the functions that could not be converted until it finally compiled. The only part Mozilla seems to use is the IPC portion for out of process plugins, which we don't support anyway, but more to the point can't support: it requires posix_spawn, which does not exist in 10.4 and would be very hard to emulate. Fortunately Mozilla offers a way to blacklist plugins to always run in-process, and all plugins are blacklisted to do so in TenFourFox, so we don't ever run that code. We will have to revisit this problem when Mozilla goes to one-tab-per-process, however, because this code will be needed for it.

Things that need to be tested: I believe that our old update notification system should still work, but please let me know if you don't get update announcements. There will be one more beta prior to release, so you should get flagged when beta 2 arrives (don't be quick to update; wait and see if you get prompted). We will not support the auto-update strategy because frankly if you're using a Power Mac, I know you appreciate control over your setup and not being forcibly updated unless you explicitly ask. Also, like any beta, there may be Firefox-general bugs and you should be prepared for those, although I have been using TenFourFox 5 myself for the last week and it seems really quite solid.

Well, read the release notes, then go get it and tell me what you think:

• G3
• G4/7400
• G4/7450
• G5