Benoit Jacob

In order to get hardware acceleration, users need to have recent graphics drivers in addition to good hardware. Have they?

To find out, I used a script that parses Firefox 4 crash reports, which now report on attempted/successful/failed graphics features. Below are some findings, based on crash reports collected since the Firefox 4 release. The implicit approximation made here is that crashiness is overall independent from these graphics features, so that numbers of crashes are proportional to numbers of users. This should be a decent approximation, since crash stats show that these graphics features are not among the top causes of crashes.

Layers (compositing, etc.) acceleration

Layers acceleration is what handles compositing, image resizing/rotation, and video colorspace conversions.

Here are success rates per operating system and per graphics system used. Notice that Windows Vista and Windows 7 try both Direct3D 10 and Direct3D 9, so the total success rate there is not just the sum of the two.

Our decision to support Direct3D 9, instead of only supporting Direct3D 10, is paying off: it greatly increases the number of users who get hardware acceleration. Even on Direct3D 10-capable Windows versions, having Direct3D 9 as a fallback gives a nice boost to our stats. But the really important part is Windows XP. Those 8 % of XP users might seem few, until one realizes that XP users account of half of the world’s Internet users. 8 % of all XP users would be more than 50 million people. While most (92 %) of XP users have outdated graphics drivers and/or hardware, those 8 % include many people who are tech-conscious enough to have recent graphics drivers installed: it is safe to bet that many of them also care about getting hardware acceleration in their browser. Also, we’ll see below that 21% of Windows XP users actually get WebGL, which means that they have recent enough drivers, so it seems that the reason why only 8 % get accelerated layers is lack of support for features we require there, such as 4Kx4K textures. Then again, we must be very conservative with layers acceleration, as enabling it on too slow graphics systems can ruin the user experience.

The 99% figure on Mac is to be taken with a grain of salt: this is only among users of Mac OS 10.6.3 and newer. Most of hardware acceleration is disabled on older versions. The 79% figure on Linux, too, is a bit tricky: hardware-accelerated layers on Linux are disabled by default, and require manually enabling. Moreover, on Linux, they are correlated with Flash crashes, so this number might be completely biased.

WebGL

Let’s now turn our attention to WebGL.

The 21 % WebGL success rate here on Windows XP is surprisingly higher than the 8 % Direct3D 9 layers success rate. I suppose that the extra requirements we currently place on hardware to enable Direct3D 9 layers, such as the 4Kx4K textures requirement, are ruling out a lot of users.

The 80 % success rate on Mac is really among all Mac users. WebGL is only enabled on Mac OS 10.6, so what this tells is that 80% of Firefox 4 Mac users are on 10.6 and have good hardware.

The 40% success rate on Linux is going to get much higher soon, when we whitelist more recent drivers.

Finally, the Direct2D and DirectWrite success rates are basically the same as the above Direct3D 10 success rates.

Firefox 4 brings many new features in the Graphics department, notably hardware acceleration and WebGL. However, when we turned these features on by default in nightly builds around September last year, and then in Beta 7,  crash statistics and bug reports quickly showed that bugs in graphics drivers were often making these features misbehave. We reacted by selectively disabling these new features on buggy drivers, based on the large amounts of information collected by beta testers. Of course, Firefox remains fully functional: only these new features get disabled.

The resulting driver blocklist is worth reading if you want to get the most out of Firefox 4:

• Windows users with Intel cards: you need a very recent driver.
• Windows users with NVIDIA cards: you need driver version 257.21 or newer.
• Windows users with ATI cards: you need driver version 10.6 or newer.
• Instructions are also given for Mac and X11 (Linux/Unix).

Unfortunately, certain computer manufacturers do not allow end users to upgrade drivers on their own. Hopefully these manufacturers will eventually give their users these much needed graphics driver updates.

Recently I’ve come across some good solutions for common tasks with Mercurial Queues (MQ). I’ve updated our MDC page on this subject, and for greater visibility I’d like to copy that stuff here.

Splitting a patch, the easy case: per-file splitting

If you have a patch that modifies file1 and file2, and you want to split it into two patches each modifying only one file, do:

$ hg qgoto my-patch
$ hg qref -X path/to/first/file            # take changes out of current patch and back into `hg diff`
$ hg qnew -f patch-modifying-first-file    # and take that into a new MQ patch

Here, the qref -X command takes the changes to the first file out of the patch, so that they now show up in hg diff and therefore get picked up by the hg qnew -f.

Splitting a patch, the general case, including per-hunk and per-line splitting

If you need to perform finer patch splitting, for example per-hunk or even per-line, there’s a great tool for that: hg qcrecord. It’s provided by the Crecord extension. Follow the instructions on that page to install it. This extension works on your current `hg diff`. So if you had your patch as a MQ patch, you first need to take the changes out of it, using hg qref -X.

$ hg qref -X .             # take changes out of current patch and back into `hg diff`
$ hg qcrecord new-patch 

This will open a console-based dialog allowing you to select file-by-file, hunk-by-hunk, and even line-by-line, what changes you want to record into new-patch. When you first launch hg qcrecord, shows you a list of modified files:

SELECT CHUNKS: (j/k/up/dn/pgup/pgdn) move cursor; (space/A) toggle hunk/all
 (f)old/unfold; (c)ommit applied; (q)uit; (?) help | [X]=hunk applied **=folded
[X]**M hello.cpp

Let’s now press ‘f’ to unfold hello.cpp:

SELECT CHUNKS: (j/k/up/dn/pgup/pgdn) move cursor; (space/A) toggle hunk/all
 (f)old/unfold; (c)ommit applied; (q)uit; (?) help | [X]=hunk applied **=folded
[X]    diff --git a/hello.cpp b/hello.cpp
       2 hunks, 4 lines changed

   [X]     @@ -1,4 +1,5 @@
            #include <iostrea>
      [X]  +#include <cmath>
           #include <cstdlib>

           double square(double x)

   [X]     @@ -8,5 +9,6 @@

            int main()
            {
      [X]  -  std::cout << square(3.2) << std::endl;
      [X]  +  double x = 2.0;
      [X]  +  std::cout << std::sqrt(square(x)) << std::endl;
           }

Folding multiple patches into one

The hg qfold command allows you to merge a patch into another one:

$ hg qgoto my-first-patch      # go to first patch
$ hg qfold my-second-patch     # fold second patch into it

Pushing only one patch, reordering as needed

Mercurial 1.6 introduced the new hg qpush --move command, doing exactly that. This allows to reorder one’s patch queue without resorting to manually editing the series file.