Out of curiosity, did you actually read the article? The work he did to make Firefox faster was in Firefox' code, not in the demos. The only changes he made in the demos were to better expose the underlying issues causing performance differences (like adding more fish to the tank demo so that FPS limiting isn't confounding the results).
Firefox 4 is already at RC stage and won't be changed for the final release unless a showstopper bug is found. More likely is that they'll land for Firefox 5, which is supposedly coming 3 months from now. It's also possible that some of the fixes could land for a 4.x or 4.0.x release if they're proven stable and relatively risk-free.
Funny enough, Firefox' "broken" fonts are thanks to using the same DirectWrite that IE9 uses. However, MS disables DWrite for fonts and uses GDI instead when running sites in compatibility mode. When running in standards mode, IE9 and Firefox have identical font rendering (there's a big MozillaZine forum thread with screenshots if you're interested). Also, some recent MS hotfixes for DWrite have noticeably improved font rendering. Have you used a recent beta with an updated system? But in the end, if you're not happy with the font rendering, you can always disable the hardware acceleration through the options.
If I recall correctly, the MS H.264 extension also caused extreme memory bloat/leakage.
Also, a lot of the rewriting you're talking about as needing to happen has in fact been going on, in the open for anyone who's interested to see. Heck, mobile Firefox already does use process isolation and it's coming to the desktop version next. The project is called electrolysis. Honestly, a lot of what you're saying sounds like the usual uninformed trolling about how old Gecko is and how badly it needs to be overhauled as if that work isn't being done. It's a foolish assumption because all Gecko development happens in the open and anyone with the desire to can see and confirm that in fact large portions of the code have been rewritten during the Gecko 2.0 development window (what do you think they've been spending the last 18 months doing?) and are continuing to be already for post-2.0 Gecko.
Unfortunately, I've seen it on three different systems now. All Win7. Two are Minefield (well, my own trunk builds anyway) and the other Fx4b8/9. But you're absolutely right that without any reliable steps to reproduce, little can be done about it, as painful as it is.
Firefox SVG support has been subject to a lot of work during the 4.0 development cycle. If you have "crappy" SVG issues in the beta, I'd recommend filing a bug (preferably with a testcase attached). From following a lot of bugs, I can tell you that there is a lot of genuine desire to support SVG as a first-class citizen in the Mozilla world, so I'd be surprised if your bugs (with testcases!) were ignored.
The ghost tab issue is a hard release blocker and actually seems to have been fixed recently. With any luck, you won't see that problem anymore in beta10.
The best part about the Acid3 complaints are that Firefox' missing 3 points are for SVG Fonts, which are becoming optional for support in SVG 2.0 anyway. And yet people are fixated on those 3 points as if they are some giant indictment of Firefox' slipping standards support.
My question is whether Hixie will eventually change Acid3 to reflect the change in status since it doesn't seem right to have a standards compliance test that faults browser vendors for not supporting optional parts of a specification. Doesn't exactly seem fair to me. Maybe Acid3.1?
Are you on Vista or Win7 by chance? There is a known bug with DirectWrite that can cause hangs on startup due to font enumeration. It's one of the hard blockers mentioned in TFA that has to fixed before release.
Tabs on Top is optional. They have default settings depending on the host OS, but it can be enabled/disabled by clicking on the Firefox Button > Options > Tabs on Top.
JM is very much on trunk already. It's not something that's enabled via.mozconfig. Look for the methodjit options in about:config. Content is on, Chrome is off currently.
Linux builds don't get PGO due to spotty GCC support, which may be a large part of the problem. Mozilla has been trying to switch to GCC 4.5.x with its improved PGO support as their official Linux compiler, but have run into issues with doing so thus far. Bug 559964 is the primary bug tracking their progress. Take a look at the bug dependencies if you're interested in the problems they've hit so far.
You're assuming that the developers who implemented the hardware acceleration support were doing so instead of fixing those bugs, which is a big and likely incorrect assumption. It's a tired straw man argument.
Slashdot Mirror
File a bug with a testcase and CC :bz?
How does Firefox 4 compare?
Jetpack should make extension compatibility a much better experience as it gains traction. https://jetpack.mozillalabs.com/
Mozilla is working on multiprocess. The project is called electrolysis and is already being used for mobile Firefox.
Out of curiosity, did you actually read the article? The work he did to make Firefox faster was in Firefox' code, not in the demos. The only changes he made in the demos were to better expose the underlying issues causing performance differences (like adding more fish to the tank demo so that FPS limiting isn't confounding the results).
Firefox 4 is already at RC stage and won't be changed for the final release unless a showstopper bug is found. More likely is that they'll land for Firefox 5, which is supposedly coming 3 months from now. It's also possible that some of the fixes could land for a 4.x or 4.0.x release if they're proven stable and relatively risk-free.
Funny enough, Firefox' "broken" fonts are thanks to using the same DirectWrite that IE9 uses. However, MS disables DWrite for fonts and uses GDI instead when running sites in compatibility mode. When running in standards mode, IE9 and Firefox have identical font rendering (there's a big MozillaZine forum thread with screenshots if you're interested). Also, some recent MS hotfixes for DWrite have noticeably improved font rendering. Have you used a recent beta with an updated system? But in the end, if you're not happy with the font rendering, you can always disable the hardware acceleration through the options.
If I recall correctly, the MS H.264 extension also caused extreme memory bloat/leakage.
Also, a lot of the rewriting you're talking about as needing to happen has in fact been going on, in the open for anyone who's interested to see. Heck, mobile Firefox already does use process isolation and it's coming to the desktop version next. The project is called electrolysis. Honestly, a lot of what you're saying sounds like the usual uninformed trolling about how old Gecko is and how badly it needs to be overhauled as if that work isn't being done. It's a foolish assumption because all Gecko development happens in the open and anyone with the desire to can see and confirm that in fact large portions of the code have been rewritten during the Gecko 2.0 development window (what do you think they've been spending the last 18 months doing?) and are continuing to be already for post-2.0 Gecko.
In case you're interested, here's a list of the major work done on Gecko during the 2.0 development timeframe.
http://forums.mozillazine.org/viewtopic.php?f=23&t=1961093
Umm, wrong... http://v8.googlecode.com/svn/data/benchmarks/v6/run.html
Also, a "javascript rendering engine"???
Firefox 4 is going to be the last release that runs on Win2K, for what it's worth.
Unfortunately, I've seen it on three different systems now. All Win7. Two are Minefield (well, my own trunk builds anyway) and the other Fx4b8/9. But you're absolutely right that without any reliable steps to reproduce, little can be done about it, as painful as it is.
Firefox SVG support has been subject to a lot of work during the 4.0 development cycle. If you have "crappy" SVG issues in the beta, I'd recommend filing a bug (preferably with a testcase attached). From following a lot of bugs, I can tell you that there is a lot of genuine desire to support SVG as a first-class citizen in the Mozilla world, so I'd be surprised if your bugs (with testcases!) were ignored.
The ghost tab issue is a hard release blocker and actually seems to have been fixed recently. With any luck, you won't see that problem anymore in beta10.
The best part about the Acid3 complaints are that Firefox' missing 3 points are for SVG Fonts, which are becoming optional for support in SVG 2.0 anyway. And yet people are fixated on those 3 points as if they are some giant indictment of Firefox' slipping standards support. My question is whether Hixie will eventually change Acid3 to reflect the change in status since it doesn't seem right to have a standards compliance test that faults browser vendors for not supporting optional parts of a specification. Doesn't exactly seem fair to me. Maybe Acid3.1?
Then you'll be happy to hear that Firefox 4 updates addons silently now by default. Unfortunately, app updates still happen on startup.
I thought they fixed that in 4.0. Have you tried one of the betas and still seen that behavior?
I too see these random bouts of "Not Responding" from time to time on the recent 4.0 betas. I can't even seem to find a bug filed for it.
In Firefox 4, add-on updates now install silently instead of prompting on startup.
Tabs in the title bar was recently landed on the trunk. If it's not enabled for beta 9, it will be in beta 10.
Are you on Vista or Win7 by chance? There is a known bug with DirectWrite that can cause hangs on startup due to font enumeration. It's one of the hard blockers mentioned in TFA that has to fixed before release.
Tabs on Top is optional. They have default settings depending on the host OS, but it can be enabled/disabled by clicking on the Firefox Button > Options > Tabs on Top.
JM is very much on trunk already. It's not something that's enabled via .mozconfig. Look for the methodjit options in about:config. Content is on, Chrome is off currently.
Linux builds don't get PGO due to spotty GCC support, which may be a large part of the problem. Mozilla has been trying to switch to GCC 4.5.x with its improved PGO support as their official Linux compiler, but have run into issues with doing so thus far. Bug 559964 is the primary bug tracking their progress. Take a look at the bug dependencies if you're interested in the problems they've hit so far.
s/arewethereyet.com/arewefastyet.com
You're assuming that the developers who implemented the hardware acceleration support were doing so instead of fixing those bugs, which is a big and likely incorrect assumption. It's a tired straw man argument.