> So I set it to 0, to see how fast it can/really/ > render, and found that the 4ms timeout was the > limiting factor.
While that's reasonable, I think presenting both numbers (along with that explanation) would make a much stronger case for "Firefox kicks the other browsers butts on this benchmark" (which it does!)
As for IE9, the measurements Robert did of IE9 showed that it sets the timeout clamp to 4ms unless there's canvas interaction going on, in which case the clamp ends up at 3.5ms. Not quite the same as 0, and we didn't make a big stink of it exactly...;)
If you set the minimum timeout to 0, you're comparing apples and oranges, since the other browsers have a minimum of at least 4. You should set it to 4 (which is the default value in the nightly anyway!).
OpenGL and Direct3D are pretty equivalent APs in terms of capabilities. Firefox uses OpenGL on Mac. It tried to use OpenGL on Linux, but discovered that this causes some drivers to crash. In fact, even detecting the driver type causes it to crash. The problem has since been solved by just using a separate process at startup to detect the driver type so crashy drivers can be blacklisted, so OpenGL should be used in on Linux in the future.
Direct2D (which is what does 2d stuff on Windows) is something that has no equivalent on Mac and Linux. Render can sometimes do an almost-equivalent job if you get lucky with your card and drivers (e.g. a lot of the IE "hardware acceleration" tests are way faster on Linux than on Mac when you get lucky in this way). To deal with this issue Mozilla is basically going to implement a cross-platform accelerated 2d graphics layer (on top of OpenGL in the Linux case) and use that. See http://blog.mozilla.com/joe/2011/04/26/introducing-the-azure-project/
But yes, this would all work better on Linux if the drivers worked without crashing, if there were a decent system 2d API for accelerated graphics, etc...
Of course Mozilla itself is aiming at a Firefox 6 release in August, so a "first beta" in Sept/Oct would be a neat feat, a month or two after final release!
On the other hand, distros are known to purposefully compile with options that make the resulting build slower for various "system integration" reasons. So I'm not holding my breath on them doing the right thing here..
> What's funny about FF bugs is the continual denial,
Uh... I have yet to meet a single Firefox developer who doesn't think Firefox on Linux is slower than on Windows, with the difference in compiler quality being one of the major contributors to the difference. Care to point to a place where someone denied this?
There's quite a bit of discussion about how to do UI changes in this setup, yes. I don't think anyone is planning to roll out sweeping UI changes within a single 18-week cycle; they would land on mozilla-central, get disabled after the aurora merge, and keep getting disabled until people are happy with them on mozilla-central. Just like any other big feature, by the way; just because something is in mozilla-central doesn't mean it ends up in the next final release.
Chrome has so far sidestepped this issue by not making UI changes, for the most part.
Because the old promise for point updates was that they did not significantly change internal APIs (not true for the way WebM was integrated) and were generally limited to security and stability fixes (something that WebM clearly is not).
All that's happened is that this promise is gone. There is no more "minor" vs "major" update distinction. Updates are just updates. They add features, or not, if none are ready; in that case the update will just have security patches. Updates can always change internal APIs.
> If they are no longer doing that and the changes > will be more minor then all they have achieved is > version number inflation.
No. What they have achieved is getting web features into users' hands quicker. Please don't confuse web features and UI features.
As a simple example, WebM support was done in July 2010 or so, but didn't end up in a final release until March 2011. That's 8 extra months of having to watch Youtube via Flash for users. There are lots and lots of web-facing features which don't change the UI at all in Firefox 4 that could have shipped in summer 2010 or in fall 2010. Doing June and October releases last year would have been really good, but the infrastructure just wasn't in place for that at the time.
1) There will be work going into handling add-on compatibility more smoothly than before. There are plans to bump the compat version on AMO-hosted add-ons automatically, unless they're flagged as possibly being broken. In the latter case the add-on developer will be asked to update it, of course.
2) There should be much less in the way of churn between versions for web developers, reducing the need to check layouts.
3) There should be much less in the way of UI churn between versions, reducing the need for updated tutorials and people getting used to new UI.
In particular, Chrome has been on a rapid release cycle for a year now; how much has their UI changed in that time?
> but with a major release people will want to know > what added benefit it brings
For what it's worth, not a single developer I've talked to is worrying about that. The current plan is to release things as they're ready and not worry about what version number marketing decides to put on it.
For what it's worth, Mozilla supported using python in addition to JavaScript to write extensions for a number of years. No one actually used this functionality; it's now being removed to simplify the code.
So you're completely right about Python being used on the web: if it didn't even get used in an environment where you could assume support, the chicken/egg problem on the web is insuperable.
Except that NaCl is architecture-specific, thus defeating the whole point of using a web app (or for that matter a scripting language) in the first place.
If you look at the screenshots, only the first one shows emails. The other ones have them elided.
That first screenshot is the list of the top 20 or so contributors to the Mozilla project over the past year. Those e-mail addresses are all over the hg log for the project, the public project mailing lists, etc. So they're not exactly a secret...
UI responsiveness is important too, yes. I agree that Chrome is currently better there, especially in the situation you tested (one tab attempting to hog all of the CPU).
The performance differences in rendering speed we're talking about can easily be seconds to tens of seconds, not milliseconds. At that point it becomes quite noticeable.
> Firefox has better performance than Chrome? No, > absolutely not.
Really? Firefox 4 is faster than Chrome 10 on various JavaScript tests, on various DOM tests, on a number of layout performance tests. For example, see http://download.cnet.com/8301-2007_4-20047314-12.html where Firefox comes out ahead on everything except the V8 JS test.
There are other tests it's slower on, of course (V8 JS included).
And as I said both are changing rapidly; the situation looks different if you compare Chrome 11 betas to Firefox 4, and will look different yet again when you compare Firefox 5 or Firefox 6 to the contemporaneous Chrome 14 or so.
> Fact is, memory is cheap these days.
Except on mobile devices, of course. And for 32-bit processes, which can't make use of more RAM even if they wanted to.
> Integrating the cloud makes sense but not when it's > specifically "facebook" and "twitter"
The article gives those as examples; it doesn't say that the functionality is restricted to those. Do you have a source that says it does, or did you just jump to conclusions based on your preconceptions and the desire to vent?
Slashdot Mirror
> So I set it to 0, to see how fast it can /really/
> render, and found that the 4ms timeout was the
> limiting factor.
While that's reasonable, I think presenting both numbers (along with that explanation) would make a much stronger case for "Firefox kicks the other browsers butts on this benchmark" (which it does!)
As for IE9, the measurements Robert did of IE9 showed that it sets the timeout clamp to 4ms unless there's canvas interaction going on, in which case the clamp ends up at 3.5ms. Not quite the same as 0, and we didn't make a big stink of it exactly... ;)
If you set the minimum timeout to 0, you're comparing apples and oranges, since the other browsers have a minimum of at least 4. You should set it to 4 (which is the default value in the nightly anyway!).
OpenGL and Direct3D are pretty equivalent APs in terms of capabilities. Firefox uses OpenGL on Mac. It tried to use OpenGL on Linux, but discovered that this causes some drivers to crash. In fact, even detecting the driver type causes it to crash. The problem has since been solved by just using a separate process at startup to detect the driver type so crashy drivers can be blacklisted, so OpenGL should be used in on Linux in the future.
Direct2D (which is what does 2d stuff on Windows) is something that has no equivalent on Mac and Linux. Render can sometimes do an almost-equivalent job if you get lucky with your card and drivers (e.g. a lot of the IE "hardware acceleration" tests are way faster on Linux than on Mac when you get lucky in this way). To deal with this issue Mozilla is basically going to implement a cross-platform accelerated 2d graphics layer (on top of OpenGL in the Linux case) and use that. See http://blog.mozilla.com/joe/2011/04/26/introducing-the-azure-project/
But yes, this would all work better on Linux if the drivers worked without crashing, if there were a decent system 2d API for accelerated graphics, etc...
Of course Mozilla itself is aiming at a Firefox 6 release in August, so a "first beta" in Sept/Oct would be a neat feat, a month or two after final release!
If everything goes right, yes.
On the other hand, distros are known to purposefully compile with options that make the resulting build slower for various "system integration" reasons. So I'm not holding my breath on them doing the right thing here..
> What's funny about FF bugs is the continual denial,
Uh... I have yet to meet a single Firefox developer who doesn't think Firefox on Linux is slower than on Windows, with the difference in compiler quality being one of the major contributors to the difference. Care to point to a place where someone denied this?
> Are any OSS contributors vetted?
Not necessarily, but their code sure is, before it's included in the product!
There's quite a bit of discussion about how to do UI changes in this setup, yes. I don't think anyone is planning to roll out sweeping UI changes within a single 18-week cycle; they would land on mozilla-central, get disabled after the aurora merge, and keep getting disabled until people are happy with them on mozilla-central. Just like any other big feature, by the way; just because something is in mozilla-central doesn't mean it ends up in the next final release.
Chrome has so far sidestepped this issue by not making UI changes, for the most part.
Because the old promise for point updates was that they did not significantly change internal APIs (not true for the way WebM was integrated) and were generally limited to security and stability fixes (something that WebM clearly is not).
All that's happened is that this promise is gone. There is no more "minor" vs "major" update distinction. Updates are just updates. They add features, or not, if none are ready; in that case the update will just have security patches. Updates can always change internal APIs.
So 64-bit IE9 isn't native by that definition, right (no JIT there)?
Whereas Firefox 4 and Chrome dev builds are?
> If they are no longer doing that and the changes
> will be more minor then all they have achieved is
> version number inflation.
No. What they have achieved is getting web features into users' hands quicker. Please don't confuse web features and UI features.
As a simple example, WebM support was done in July 2010 or so, but didn't end up in a final release until March 2011. That's 8 extra months of having to watch Youtube via Flash for users. There are lots and lots of web-facing features which don't change the UI at all in Firefox 4 that could have shipped in summer 2010 or in fall 2010. Doing June and October releases last year would have been really good, but the infrastructure just wasn't in place for that at the time.
That shouldn't have the same effect; Firebug doesn't inject any binary code.
Thanks!
I assume you're not using the "kikin" addon mentioned in the bug?
> bp-... 2011-04-14 20:01
Mind including the whole crash id, or even just the link? I'd love to fix your crash, but I sort of need to know what the crash is to do that...
Flash is already sandboxed in its own process in Firefox; not sure about Silverlight.
1) There will be work going into handling add-on compatibility more smoothly than before. There are plans to bump the compat version on AMO-hosted add-ons automatically, unless they're flagged as possibly being broken. In the latter case the add-on developer will be asked to update it, of course.
2) There should be much less in the way of churn between versions for web developers, reducing the need to check layouts.
3) There should be much less in the way of UI churn between versions, reducing the need for updated tutorials and people getting used to new UI.
In particular, Chrome has been on a rapid release cycle for a year now; how much has their UI changed in that time?
> but with a major release people will want to know
> what added benefit it brings
For what it's worth, not a single developer I've talked to is worrying about that. The current plan is to release things as they're ready and not worry about what version number marketing decides to put on it.
> Now it's much easier to keep two copies of Firefox
> next to eachother.
This was always just as easy as now. Nothing has changed in this regard.
> There is only one problem that I see, you cannot run
> them next to eachother
Sure you can; just have them use different profiles. See http://support.mozilla.com/en-US/kb/Managing%20profiles
For what it's worth, Mozilla supported using python in addition to JavaScript to write extensions for a number of years. No one actually used this functionality; it's now being removed to simplify the code.
So you're completely right about Python being used on the web: if it didn't even get used in an environment where you could assume support, the chicken/egg problem on the web is insuperable.
Except that NaCl is architecture-specific, thus defeating the whole point of using a web app (or for that matter a scripting language) in the first place.
If you look at the screenshots, only the first one shows emails. The other ones have them elided.
That first screenshot is the list of the top 20 or so contributors to the Mozilla project over the past year. Those e-mail addresses are all over the hg log for the project, the public project mailing lists, etc. So they're not exactly a secret...
UI responsiveness is important too, yes. I agree that Chrome is currently better there, especially in the situation you tested (one tab attempting to hog all of the CPU).
The performance differences in rendering speed we're talking about can easily be seconds to tens of seconds, not milliseconds. At that point it becomes quite noticeable.
> Firefox has better performance than Chrome? No,
> absolutely not.
Really? Firefox 4 is faster than Chrome 10 on various JavaScript tests, on various DOM tests, on a number of layout performance tests. For example, see http://download.cnet.com/8301-2007_4-20047314-12.html where Firefox comes out ahead on everything except the V8 JS test.
There are other tests it's slower on, of course (V8 JS included).
And as I said both are changing rapidly; the situation looks different if you compare Chrome 11 betas to Firefox 4, and will look different yet again when you compare Firefox 5 or Firefox 6 to the contemporaneous Chrome 14 or so.
> Fact is, memory is cheap these days.
Except on mobile devices, of course. And for 32-bit processes, which can't make use of more RAM even if they wanted to.
> and figure out how to run Firefox extensions on there
How much work do you estimate this to be, exactly? Chances are, your estimate is low.
> have much better memory use and performance.
Firefox has better performance and memory use than Chrome in many cases. It's worse in others. Both browsers are improving.
How would having only one implementation be better for consumers than two competing ones?
> Integrating the cloud makes sense but not when it's
> specifically "facebook" and "twitter"
The article gives those as examples; it doesn't say that the functionality is restricted to those. Do you have a source that says it does, or did you just jump to conclusions based on your preconceptions and the desire to vent?