Firefox 4 for Mac OS X: Under the Hood

Looking under the hood of a carFirefox 4 will be an exciting release and we’ve made a number of improvements specific to Mac OS X. Users will benefit primarily in terms of speed, stability, and security. We’ve come a long way since Firefox 3 for Mac OS X.

First, we’ve switched from a ppc/i386 universal binary to an i386/x86_64 universal binary. The default architecture on Mac OS X 10.6 will be x86_64. The default architecture on Mac OS X 10.5 will be i386. You will be able to run in i386 mode on Mac OS X 10.6 if you choose to do so but you will not be able to run in x86_64 mode on Mac OS X 10.5. Performance is the primary motivation for the move to x86_64. These numbers comparing Firefox 4b7 i386 to Firefox 4b7 x86_64 on Mac OS X 10.6.4 give some idea of the kinds of gains we’re seeing from the architecture change alone:

  • Cold startup: x86_64 is ~26% faster
  • Warm startup: x86_64 is ~5% faster
  • MS Psychadelic Browsing Demo: x86_64 is ~540% faster
  • MS Speed Reading Demo: x86_64 is ~35% faster

A big part of this is the availability of more CPU registers, but there are a number of other factors in play such as the ABI and the caching of system libraries. If most of your other applications are x86_64, and this is the case on most Mac OS X 10.6 systems, then x86_64 system libraries are more likely to be cache-hot. Your mileage may vary depending on your exact system configuration.

We dropped ATSUI for text rendering and moved to Harfbuzz and Core Text. The move to Harfbuzz for many operations was done for security reasons and in order to expose advanced typographic features. Font handling is difficult in general, and even more so in web browsers. We’d prefer to depend on open source font code if possible because we can patch it quickly and participate in improving it.

We enabled OpenGL accelerated layer composition. This stage in the rendering pipeline is where we composite independently-rendered regions of a web page for your screen. Accelerating it helps us most when resizing images and video. GPUs are much better at performing those sorts of transformations than CPUs. For more information, see this post from Joe Drew. We hope to accelerate the rest of our rendering pipeline on Mac OS X soon.

We also added support for the Cocoa NPAPI event model and the Core Animation NPAPI drawing model. These specifications are a big step forward for browser plugins on Mac OS X. They are easier to develop for, properly documented, and designed with IPC in mind. As of version 10.1, Adobe’s Flash plugin supports Cocoa NPAPI. Which leads me to the next improvement…

Firefox 4 will run many plugins out-of-process on Mac OS X. All of your plugins will be out-of-process if you’re running the x86_64 version of Firefox. If you’re running the i386 version of Firefox we’ll run some popular plugins, such as Flash 10.1+, out-of-process but others will run in-process for performance and user experience reasons. And yes – the x86_64 version of Firefox will be able to use i386 plugins.

Those are the major Mac OS X-specific changes but we’ve also made a large number of minor improvements for Mac OS X. Combined with all of the great cross-platform improvements like our new JavaScript engine, WebM, and better HTML5 support, Firefox 4 should take the web to a whole new level for our users.