On Windows, Chrome's numbers are hard to measure because they use a 500KB installer that then downloads the actual browser. But according to http://news.cnet.com/8301-30685_3-20045776-264.html Chrome 10 on Windows is 26MB. Firefox 4 is 12MB.
The thing with Mac OS X is that apple sort of goes out of their way to make it hard to support multiple versions at once. For a simple example, there is no text measurement API that works on both 10.4 and 10.6: if you want to support both in an app that needs to measure text (something a browser sort of has to do), you need two different codepaths.
So the options were to support only 10.4 and 10.5, support only 10.5 or 10.6, or do lots more work (way more than needed to support Win2k/XP while also supporting Vista/7) to support all three. Given the fraction of the user base, even just the Mac user base, on 10.4, it was decided to not support it.
Note that all the discussion about this is publicly archived (and happened on public mailing lists in the first place) if you care to read it...
Looks like the main issue is the use of -moz-linear-gradient without a corresponding -webkit version, and the use of -moz-calc.
Which is sort of unfortunate... on the other hand, this page is basically part of the browser UI on first run; it's not a general page that you'd want to link someone to.
To oversimplify, there are two kinds of hardware acceleration that Firefox implements. There's acceleration of drawing ("2d" acceleration) and acceleration of compositing ("3d" acceleration).
On Windows Vista and Windows 7, both are implemented. On WinXP, Win2k, and Mac OS 10.6, 3d acceleration is implemented, but 2d is not. On Linux, 3d acceleration is supported with the binary nvidia driver, and 2d acceleration happens "for free" if your driver's XRender implementation is good. This last part also worked on Linux in Firefox 3.6, I believe.
If you're testing on http://demos.hacks.mozilla.org/openweb/HWACCEL/ then you're gated on the speed of drawImage, which is 2d acceleration. Hence you'll get fast performance on Windows 7/Vista and on Linux with a good Xrender, but not elsewhere.
> Anyone want to write a Gaussian Blur filter in > ECMAScript, and run it on a four-million-pixel, > 4-channel raster image?
So like https://bug495499.bugzilla.mozilla.org/attachment.cgi?id=380489 more or less, but doing gaussian blur instead of desaturate? The image there is a 4,096,000 pixel image (2560x1600); the desaturate filter takes 250ms on my machine in Firefox 4 (and that includes getting the bits out of the image and into JS and then back into image form).
Of course it's a bit slower in other browsers, but only by a factor of 2-4 or so over here.
More precisely, the standard says that the minimum timeout should be _at_least_ 4 ms. Delays below 4ms are not allowed. Delays over 4ms are allowed at the browser's discretion. For example, IE9 uses a 15ms minimum when on battery. Firefox 5 and upcoming versions of Chrome will both use a 1000ms minimum in background tabs. That sort of thing.
So the only browser violating the standard here is IE9, which is in fact going below 4ms consistently.
The short story is that IE9 has very very good CSS 2.1 support (probably better than anyone else; being late to the game actually helps with that) and fairly limited CSS3 support. Of course most of the CSS3 modules are still in the pie-in-the-sky stage; the only notable exceptions are Color, Backgrounds&Borders, and Selectors, and IE9 may support part of Backgrounds&Borders.
As far as HTML5 goes, IE9 is somewhat behind the curve on the new stuff, as far as I can tell (about where other browsers were a year ago), but way better than IE8. For one thing, it supports . And SVG, for that matter.
Firefox 4 should definitely make scrolling faster in many cases (but may depend on your graphics hardware and drivers, like so many other things with hardware acceleration).
The thing is, the other browsers do NOT have the "same features" when running on XP.
For example, Firefox only does 2d hardware acceleration on Windows at the moment, and only on Vista/Win7. It does 3d hardware acceleration everywhere, though.
Now I think the MS decision is not the right one, but is it qualitatively different from Mozilla not shipping a Firefox 4 on PPC due to the lack of a JIT backend for that architecture and hence not being able to deliver equivalent JS performance?
Quantitatively, it's different: there are way more WinXP users than MacOS users on PPC hardware. But qualitatively?
Right this second, likely IE. There was a last-minute security fix that introduced some undesirable lag into drawImage in Firefox and makes the fishtank a bit slower. Making it faster again isn't going to make Firefox 4, but will make Firefox 5 in a few months.
> or for a false idea to gain wide acceptance > without being tested
That depends on the field. It's actually _very_ easy for this to happen in medicine, where once something is "accepted" (often on the basis of just one study) further experimentation on the matter is prohibited as unethical....
You can get the incident ID by loading about:crashes in the browser; this should give you a list of incident IDs, with links to the crash data for them. Either the IDs or the URIs they link to would be great. Thank you!
May I recommend filing a bug on your X package with Ubuntu, since it's clearly buggy?
Might want to file one on Chrome too, in case they want to work around the bugs, I suppose... This sort of thing is why Firefox is shipping with WebGL disabled on most Linux graphics setups.:(
I'm pretty sure that quota is not in fact checked yet. For one thing, I'm not sure there are reliable ways to check quotas in all cases (short of trying to write and failing)...
> Another thing I don't understand is why there is a > constant need for new standards
Some of the new standards are web developers keep asking for new features. Part of this is an expanding set of use cases, and part is expanding demographics. Now some of these revisions are more substantive than others...
For example, HTML3 introduced the and tags because authors wanted those capabilities. HTML4 introduced and various other things. XHTML introduced an XML formulation of HTML. HTML5 introduces new types of form controls so you can write or whatnot instead of enforcing that in JS. CSS has been introducing various things ranging from more control over the way line-breaking happens for the text to vertical text (which is of no use to Western pages, but very desirable in some CJK pages).
On the other hand, some stands (large parts of HTML5, say) are about just standardizing de-facto behavior that was never described in a standard.
Slashdot Mirror
Anyone who wants to get on a plane? ;)
On OS X 10.6 Firefox 4 runs 64-bit by default. The download includes both the 64-bit and 32-bit binaries on Mac.
On Linux, the builds are there but not officially supported, apparently. See http://releases.mozilla.org/pub/mozilla.org/firefox/releases/4.0/linux-x86_64/
Chrome is a smallish download?
On Mac: Chrome 10: 35MB
Firefox 4: 28MB
On Linux: Chrome 10 32-bit rpm: 30MB
Firefox 4 32-bit package: 13MB
On Windows, Chrome's numbers are hard to measure because they use a 500KB installer that then downloads the actual browser. But according to http://news.cnet.com/8301-30685_3-20045776-264.html Chrome 10 on Windows is 26MB. Firefox 4 is 12MB.
The thing with Mac OS X is that apple sort of goes out of their way to make it hard to support multiple versions at once. For a simple example, there is no text measurement API that works on both 10.4 and 10.6: if you want to support both in an app that needs to measure text (something a browser sort of has to do), you need two different codepaths.
So the options were to support only 10.4 and 10.5, support only 10.5 or 10.6, or do lots more work (way more than needed to support Win2k/XP while also supporting Vista/7) to support all three. Given the fraction of the user base, even just the Mac user base, on 10.4, it was decided to not support it.
Note that all the discussion about this is publicly archived (and happened on public mailing lists in the first place) if you care to read it...
Are you testing IE9 in forced-compat mode or something? It does a lot better than that on Acid3 normally.
Looks like the main issue is the use of -moz-linear-gradient without a corresponding -webkit version, and the use of -moz-calc.
Which is sort of unfortunate... on the other hand, this page is basically part of the browser UI on first run; it's not a general page that you'd want to link someone to.
To oversimplify, there are two kinds of hardware acceleration that Firefox implements. There's acceleration of drawing ("2d" acceleration) and acceleration of compositing ("3d" acceleration).
On Windows Vista and Windows 7, both are implemented. On WinXP, Win2k, and Mac OS 10.6, 3d acceleration is implemented, but 2d is not. On Linux, 3d acceleration is supported with the binary nvidia driver, and 2d acceleration happens "for free" if your driver's XRender implementation is good. This last part also worked on Linux in Firefox 3.6, I believe.
If you're testing on http://demos.hacks.mozilla.org/openweb/HWACCEL/ then you're gated on the speed of drawImage, which is 2d acceleration. Hence you'll get fast performance on Windows 7/Vista and on Linux with a good Xrender, but not elsewhere.
> Anyone want to write a Gaussian Blur filter in
> ECMAScript, and run it on a four-million-pixel,
> 4-channel raster image?
So like https://bug495499.bugzilla.mozilla.org/attachment.cgi?id=380489 more or less, but doing gaussian blur instead of desaturate? The image there is a 4,096,000 pixel image (2560x1600); the desaturate filter takes 250ms on my machine in Firefox 4 (and that includes getting the bits out of the image and into JS and then back into image form).
Of course it's a bit slower in other browsers, but only by a factor of 2-4 or so over here.
More precisely, the standard says that the minimum timeout should be _at_least_ 4 ms. Delays below 4ms are not allowed. Delays over 4ms are allowed at the browser's discretion. For example, IE9 uses a 15ms minimum when on battery. Firefox 5 and upcoming versions of Chrome will both use a 1000ms minimum in background tabs. That sort of thing.
So the only browser violating the standard here is IE9, which is in fact going below 4ms consistently.
It's a recently-proposed standard; the de-facto standard until recently was 10ms.
But even more interestingly, IE goes below 4 milliseconds in some cases, which just happens to improve their score on tests like this.
The short story is that IE9 has very very good CSS 2.1 support (probably better than anyone else; being late to the game actually helps with that) and fairly limited CSS3 support. Of course most of the CSS3 modules are still in the pie-in-the-sky stage; the only notable exceptions are Color, Backgrounds&Borders, and Selectors, and IE9 may support part of Backgrounds&Borders.
As far as HTML5 goes, IE9 is somewhat behind the curve on the new stuff, as far as I can tell (about where other browsers were a year ago), but way better than IE8. For one thing, it supports . And SVG, for that matter.
Well, let's see. His most recent code commit to emacs was in November 2009, looks like: http://git.savannah.gnu.org/cgit/emacs.git/log/?qt=author&q=stallman
So at least that recent, even assuming he's not worked on anything else.
Firefox 4 should definitely make scrolling faster in many cases (but may depend on your graphics hardware and drivers, like so many other things with hardware acceleration).
If you have Firebug running, you're getting slow JS as well: the Firebug JS debugger disables the JITs.
The thing is, the other browsers do NOT have the "same features" when running on XP.
For example, Firefox only does 2d hardware acceleration on Windows at the moment, and only on Vista/Win7. It does 3d hardware acceleration everywhere, though.
Now I think the MS decision is not the right one, but is it qualitatively different from Mozilla not shipping a Firefox 4 on PPC due to the lack of a JIT backend for that architecture and hence not being able to deliver equivalent JS performance?
Quantitatively, it's different: there are way more WinXP users than MacOS users on PPC hardware. But qualitatively?
You're quite welcome!
This was happening on Windows for users without hardware acceleration.
It's fixed in the RC, and has been fixed in the nightlies for a while now.
Right this second, likely IE. There was a last-minute security fix that introduced some undesirable lag into drawImage in Firefox and makes the fishtank a bit slower. Making it faster again isn't going to make Firefox 4, but will make Firefox 5 in a few months.
> or for a false idea to gain wide acceptance
> without being tested
That depends on the field. It's actually _very_ easy for this to happen in medicine, where once something is "accepted" (often on the basis of just one study) further experimentation on the matter is prohibited as unethical....
You can get the incident ID by loading about:crashes in the browser; this should give you a list of incident IDs, with links to the crash data for them. Either the IDs or the URIs they link to would be great. Thank you!
May I recommend filing a bug on your X package with Ubuntu, since it's clearly buggy?
Might want to file one on Chrome too, in case they want to work around the bugs, I suppose... This sort of thing is why Firefox is shipping with WebGL disabled on most Linux graphics setups. :(
I'm pretty sure that quota is not in fact checked yet. For one thing, I'm not sure there are reliable ways to check quotas in all cases (short of trying to write and failing)...
Did it ask you to submit a crash report? If so, can you please post the incident ID here? I'll make sure it gets looked into!
> Another thing I don't understand is why there is a
> constant need for new standards
Some of the new standards are web developers keep asking for new features. Part of this is an expanding set of use cases, and part is expanding demographics. Now some of these revisions are more substantive than others...
For example, HTML3 introduced the and tags because authors wanted those capabilities. HTML4 introduced and various other things. XHTML introduced an XML formulation of HTML. HTML5 introduces new types of form controls so you can write or whatnot instead of enforcing that in JS. CSS has been introducing various things ranging from more control over the way line-breaking happens for the text to vertical text (which is of no use to Western pages, but very desirable in some CJK pages).
On the other hand, some stands (large parts of HTML5, say) are about just standardizing de-facto behavior that was never described in a standard.
> Goodbye HTML!
Good luck, and hello network effects! ;)
For what it's worth, while the url bar is indeed a lot faster, that's not really related to the JS changes.
In fact, the new method jit isn't even enabled for chrome JS by default in Firefox yet. You can flip a pref to thus enable it.