White Island

Last weekend we had the annual Mozilla Auckland outdoor activity. No-one else volunteered to organise it so once again I had us visit a volcano :-). This time, it was White Island in the Bay of Plenty.

We drove down to Whakatane on Friday night and stayed at the White Island Rendezvous Motel, which also runs the guided tour boat trip out to the island. We went out to the island on Saturday morning. Small boats weren't leaving the harbour due to tsunami fears, but our boat was cleared to leave. The boat took an hour and a half to get out to the island, then we had about two hours walking on the island, after which we had lunch on board, circumnavigated the island and returned to Whakatane. The weather was fantastic for the whole trip --- sunny, warm, a slight swell on the bow on the way out but nothing to speak of on the way back.

The island is amazing. It's basically just a large crater with a high rim to the west, north and east. Inside the rim is an astonishing, completely barren landscape. The crater walls are bare rock, much of it loose, heavily eroded by rainfall. The floor is rocks, ash, and mineral formations, plus some fumaroles, boiling water and mud, and the crater lake itself. The lake is amazing: quite large, constantly roiling, hot (currently around 67 degrees C, 152 F), and with a pH of -0.4, considerably stronger than battery acid. The fumaroles and the lake itself constantly belch a mix of steam and sulphuric fumes. The steam plume is huge, constantly visible from Whakatane in clear weather. The fumes shift around in the wind; when they blow your way, you start coughing and spluttering --- fortunately the tour company provides masks with fliters. The place is both hellish and totally fascinating, and beautiful in its own way. (Odd that we would consider something attractive that's so inimical to life!)

The crater area contains the remains of sulphur mining operations. They're a lovely example of industrial ruins, and look older than they actually are due to the spectacularly corrosive environment.

As a nice bonus, we encountered dolphins on the way to the island and on the way back, and a seal too! On the return trip there must have been hundreds of dolphins in the group; for a while, wherever you looked you could see dolphins leaping out of the water at every moment. They loved playing in the wake of the boat, and the boat's skipper was adept at encouraging them. Seeing those magnificent animals just having fun was incredibly exhilarating --- I just wanted to laugh, or cry, with joy.

We capped off the day with a visit to Ohope beach, which was lovely, and dinner at the "Africa" cafe, which was wonderful South African food, although I think they were overwhelmed by the fifteen of us --- me, Chris Double, Chris Pearce, Matthew Gregan, Karl Tomlinson, Daniel Holbert, Jonathan Watt, Cameron McCormack, plus Doug Schepers from the W3C, plus a few partners and family members. All in all, an excellent adventure!

Investigating Performance Differences Between Firefox 4 And IE9

As I explained in my last post, Microsoft's PR about "full hardware acceleration" is a myth. But it's true that some graphics benchmarks consistently report better scores for IE9 than for Firefox, so over the last few days I've been looking into that. Below I'll explain the details what I've found about various commonly-cited benchmarks, but the summary is that the performance differences are explained by relatively small bugs in Firefox, bugs in IE9, and bugs in the benchmarks, not due to any major architectural issues in Firefox (as Microsoft would have you believe).

FishIE Tank This is one of many 2D canvas demos that focus on drawing images with various transforms. Firefox 4 RC spends a lot of its time doing security checks for the drawImage call, plus there are some smaller inefficiencies in our drawImage code. I added a simple cache to avoid security checks, and fixed other inefficiencies, and the resulting builds are now slightly faster than IE9 RC1 on my system.(Although since both browser get 60fps for 1000 fish, I had to modify the test to use 2000 fish to see any differences.)

Speed Reading This is also drawImage-heavy but exercises a path that wasn't well optimized in our D2D backend. The above builds include a tweak for that path, and are slightly faster than IE9 RC1 on my system on this test.

GUIMark 2 Flash and HTML5 Some reports show differences between Firefox and IE9 on those benchmarks, but on my laptop their performance is very similar, except for HTML5 Text where Firefox is a bit faster.

Mr Potato Gun, Preschool and HWACCEL These benefit hugely from the improvements in the builds I linked to above, but our score is still lower than IE9's. That's because these tests animate using setTimeout with a delay of zero, and count how may times the animation callback fires per second. In Firefox, delays of zero are clamped to a minimum of 10ms, but in IE9 they're clamped to a minimum of 4ms. In these benchmarks, the actual painting is incredibly fast in Firefox and IE9, so the limiting factor is this timeout delay, and IE9 gets 2.5x of our score. This difference is artificial and does not affect what users see on the screen, because it's impossible to display more than about 60 frames per second under any normal circumstances --- I have previously discussed this on my blog. In these tests the user will just see 60 frames per second in IE9 and Firefox. (HWACCEL actually clamps its reported FPS value to "60+", which is sensible, but some sites are reporting numbers higher than 60 anyway, which is strange; they must have modified the test or be using an old version of it.)
In any case, post-FF4 we will change our timeout clamp to 4ms because that's what the spec says now.

But wait, there's more! My testing shows that in the above demos IE9 consistently clamps to less than 4ms --- about 3.2ms. In my test, if you click on the "run with draw" button you get 1000 callbacks in about 3200ms. If you click on the "run without draw" button you get 1000 callbacks in about 4000ms as expected. The only difference is that "run with draw" draws to a canvas in each iteration, and "run without draw" doesn't! It's definitely actual drawing to a canvas that triggers the reduced clamp; if instead of drawing you do some canvas operations that don't trigger drawing (e.g. a save()/restore() pair), you get the 4ms clamp. This is clearly a bug per spec, and I've reported it. (You won't be able to read the bug report without a Microsoft Connect account.) It's certainly both very strange and very convenient for Microsoft's test scores!

Santa's Workshop Microsoft had a whole blog post about how Firefox's slow performance on this test was due to us not using "full hardware acceleration". But they guessed wrong --- hey, we're open source, they could have checked :-). My profiling shows that we spend less than 8% of the time painting on my laptop; the rest of the time is tied up in script execution and DOM manipulation. In particular our implementation of setAttribute and getAttribute for SVG transform attributes is pretty bad. We have a plan for fixing that. (The test is also quite stupid; it animates transforms using lots of string munging, instead of using the faster and more convenient SVG DOM API.) Anyway, it's nothing to do with hardware acceleration.

PS, please don't bother posting all your test results in comments unless they're particularly interesting. Ta :-).

The Myth Of "Full Hardware Acceleration"

A browser that "fully hardware-accelerates the entire Web platform" shouldn't have any trouble with a simple HTML scrolling testcase, should it? Try this testcase in the browsers on your machine. Running fullscreen on my laptop, IE9 RC1 takes more than ten times as long as Firefox 4. That doesn't seem very accelerated to me. View the source to see that the testcase does nothing tricky.

When we designed our "layers" framework for GPU acceleration in Firefox, one of the goals was to accelerate scrolling, especially on pages where some parts of the page move as you scroll and other parts don't --- like that testcase. We have a component called FrameLayerBuilder that separates the moving parts from the stationary parts and assigns them to separate "layers". (The vicissitudes of CSS make this surprisingly difficult, but that's a topic for another blog post...) Each layer gets a VRAM buffer into which we draw the layer's contents; when we scroll, we only have to draw the content that has scrolled into view, and then we use the GPU to composite the layers together at their new positions.

I can't say for sure what IE9 is doing in this case, but experimentation suggests that it simply repaints the entire page from scratch every time it scrolls the above testcase. This does not make best use of the hardware.

I'm not here to bash IE9, just its marketing. Microsoft's message that IE9 is the apex of what a browser can do with the GPU is nonsense; in the above example, Firefox's rendering architecture makes better use of the GPU, by design. Microsoft's claim to hardware-accelerate "the entire Web platform" was always ridiculous because "the entire Web platform" contains features like HTML parsing, Javascript execution, and DOM manipulation which are simply not suitable to run on today's GPUs, and IE9 does not do so. (I'm assuming that Microsoft's "hardware acceleration" means "uses the GPU" ... if it actually means "uses hardware", that isn't saying much :-).) Microsoft's disdainful statement that "[other browsers are] choosing to accelerate only pieces of the Web platform" is hypocritical, because that's exactly what they do themselves.