Well, let's see how bad 31 is for you

I'm going to release what I have so far and see what you think. I'm typing this blog entry in 31.0b1, so I guess you can consider that an improvement over last time. Localizers, strings are frozen, so you can start your engines (see the announcement in issue 42).

I still don't have profiling working in any meaningful sense, even though I can compile and run a gprof build successfully; it looks like gprof has a bug on OS X preventing it from generating timing information, so it might be worth a dive into gcrt0.o some weekend when Scarlet Johansson is not visiting. It does generate function call counts, though, so it does run. I still need to do some more experimentation on how to get some sort of runtime instrumentation operating again.

While doing some comparisons to see what else had changed between 29 and 31, based on your glowing reviews of 29, it appears there is a "bug" in 29 that I "fixed" in 31. In Fx26, I tried using our custom CoreGraphics backend for doing web page rendering, found it too slow and occasionally crashy, and set it to use Cairo as before. In 29, Mozilla changed the backend selection code; now content couldn't be anything but CoreGraphics. In 31, I discovered this, and "fixed" it to use Cairo. Not only does setting it to CoreGraphics work, though, it's now become incredibly faster by comparison. In fact, if you're on a very fast G5 like a quad, try this trick: go to a standard-definition YouTube WebM video, start it playing (wait for the comments to load), make sure your processor is set to Highest performance, and click Full screen. This quad G5 effortlessly scales a 16:9 SD WebM video to fill an entire 1920x1080 display. Only hardware can do that. That's some hot stuff. I like.

So that was most of the problem; the rest was tuning the GC a bit more, and something that cropped up on the G4 iBook/1.33 which may have something to do with this WebM regression people are reporting on G4s. For 29, Mozilla introduced off-main-thread composition, which as we discussed uses a background thread to receive screen updates. These updates are coalesced; OMTC won't bother displaying half-frames, even though it will show full frames as fast as it receives them. On the quad (and probably any dual CPU Power Mac), this is no problem because the thread runs on another CPU and the G5 generates plenty of frames plenty fast. On G3s and G4s with no power management, this is also no problem, because they don't power throttle and run at their max clock speed, and frankly any hardware assistance at all will be much smoother than the old method. The 1GHz iMac G4 and the 450MHz Sawtooth, for example, really like 31.

On laptops or uniprocessor desktops set for power management, however, the processor may be throttled or forced to clock slew, and OMTC will be starved for frames. We shouldn't be angry with Mozilla for doing this; it's unfortunate but logical given that virtually every Intel consumer chip in the last few years has been a multicore device.

One solution is to crank CPU performance up to Highest or at least Automatic, but this isn't much of a solution for a laptop running on battery. The other solution is to turn OMTC off (set layers.offmainthreadcomposition.enabled to false and restart the browser). Now, I don't like this solution much because it's totally unsustainable: Mozilla has made no secret that main-thread compositing will be removed as soon as the last platform supports it (Linux), and cool things like asynchronous pan-and-zoom require OMTC. Disabling OMTC will be supported on 31 for as long as the ESR lasts, but I predict main-thread compositing will be removed somewhere around Fx33 or Fx34 and then you'll have to deal with the additional CPU requirements; OMTC is such a fundamental change that I cannot realistically maintain the old rendering system.

If this makes a substantial difference to WebM or other responsiveness on the systems in this group, since it doesn't really affect the outlier systems, I'm willing to ship 31 with OMTC disabled (I'll need lots of good evidence that it helps, though -- something reproducible, not anecdotal reports). However, you can be sure that it will disappear in the very near future and this will be the last stable branch we ship this way unless Mozilla finds a critical problem with it.

The only other remaining issue is shortly after startup the app beachballs for around 30 seconds. I can't make this happen on a clean profile, so I suspect an add-on is causing it, but I can't figure out which one between the affected systems; it's possible a number of them behave this way. The browser only does it the one time, so it's more of a nuisance, but it would be nice to fix. If it does it for you as well, I'd appreciate you trying to isolate what seems to set it off (make sure that it doesn't occur with a clean profile first, though).

Remember to make sure the MTE and QTE are up to date, and to undo any custom GC settings changes before you upgrade (download, release notes). I have not decided if we will release on 31.0 or 31.1, but we'll see what you think. I have the flu, so I need to go to bed. See you in the morning.