Linked by David Adams on Wed 3rd Aug 2011 16:50 UTC, submitted by _xmv
Mozilla & Gecko clones Mozilla Firefox has been listening to recent memory complains, and as a side effect tested the browser's scalability to the extreme with memshrink's improvements. The results are shocking: For 150 tabs open using the test script, Firefox nightly takes 6 min 14 on the test system, uses 2GB and stays responsive. For the same test, Chrome takes 28 min 55 and is unusable during loading. An optimized version of the script has been made for Chrome as an attempt to work-around Chrome's limitations and got an improved loading time of 27 min 58, while using 5GB of memory.
Thread beginning with comment 483643
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[8]: Comment by Praxis
by jacquouille on Thu 4th Aug 2011 13:59 UTC in reply to "RE[7]: Comment by Praxis"
jacquouille
Member since:
2006-01-02


That is all very well and good but it still doesn't address the fact that non-Windows users are treated like second class citizens; high CPU utilisation


Huh? Without more specifics I can't reply to that. But most Firefox developers use non-Windows platforms, I'd say by decreasing order it's Mac, then Linux, then Windows. So when they profile and optimize stuff, more often than not it's on Mac or Linux.

lack of NPAPI pepper extensions (which leads to craptastic Flash performance when compared to the plugin running with Safari)


I actually don't know what these are but the main guy working on NPAPI is full time on Mac... so I don't think it's an afterthought. File a bug maybe?

then there is responsiveness issues


Specifics?

lack of hardware acceleration


On Mac there has been compositing acceleration since Firefox 4. Content acceleration is not yet available on Mac as there is no Direct2D equivalent there. Direct2D means that on Windows, the hard work is already done for us, that's why Windows got content acceleration first.

On Linux, there's been XRender content acceleration for a long time, but it's not always great. Compositing acceleration is still disabled by default as due to texture_from_pixmap weirdness it's harder there than on other platforms, but there's a good chance to finally have it on by default in Firefox 9. Content acceleration by OpenGL is still not available for same reasons as on Mac.

Content acceleration on Mac and Linux is on the radar, follow the Azure project. Whenever it gets either a OpenGL or Skia backend, that will give us that.

Reply Parent Score: 2

RE[9]: Comment by Praxis
by kaiwai on Sat 6th Aug 2011 01:51 in reply to "RE[8]: Comment by Praxis"
kaiwai Member since:
2005-07-06

Huh? Without more specifics I can't reply to that. But most Firefox developers use non-Windows platforms, I'd say by decreasing order it's Mac, then Linux, then Windows. So when they profile and optimize stuff, more often than not it's on Mac or Linux.


If that is the case then they're doing a horrible job as programmers - the performance is horrible, lack of integration, out of place GUI etc.

I actually don't know what these are but the main guy working on NPAPI is full time on Mac... so I don't think it's an afterthought. File a bug maybe?


According to this: https://wiki.mozilla.org/NPAPI:Pepper

Mozilla is not interested in or working on Pepper at this time. See the Chrome Pepper pages.


Which now points to: http://code.google.com/p/ppapi/

It allows the plugin greater access to things such as hardware acceleration - Flash for example on Snow Leopard and higher (which has NPAPI Pepper extensions) uses Core Animation for example to speed up performance and reduce CPU utilisation.

Specifics?


Running heavy under a load. It comes back to the fact that they use XUL which could have been avoided had they had a small core and then built a native GUI on top of that rather than trying to write one GUI and cater it to the lowest common denominator.

On Mac there has been compositing acceleration since Firefox 4. Content acceleration is not yet available on Mac as there is no Direct2D equivalent there. Direct2D means that on Windows, the hard work is already done for us, that's why Windows got content acceleration first.

On Linux, there's been XRender content acceleration for a long time, but it's not always great. Compositing acceleration is still disabled by default as due to texture_from_pixmap weirdness it's harder there than on other platforms, but there's a good chance to finally have it on by default in Firefox 9. Content acceleration by OpenGL is still not available for same reasons as on Mac.

Content acceleration on Mac and Linux is on the radar, follow the Azure project. Whenever it gets either a OpenGL or Skia backend, that will give us that.


QuartzGL has existed and can be used on a per-application basis - there are ways to accelerate the content but Mozilla developers so far have been unwilling to dedicate the same amount of resources to Mac OS X as they do when it comes to their Windows builds.

Btw, there is nothing special about Direct2D/DirectWrite, you could do the very same thing using OpenGL - it would require more code but it is doable but it raises the greater question why wasn't there any move to create an API layer that sat on DirectX/OpenGL that delivered hardware support on all platforms at the same time?

Again, I look at the official Mozilla blog and again I see nothing in the wake of the Lion release, no information on the role that OpenGL 3.2 will play in future development, no mention about the enhanced sandboxing technology included in Lion, no mention of Xcode 4.2 moving 100% to LLVM and the role that'll play in future Firefox builds. So not only is there an issue with product that is neglected there is a complete lack of communication with the wider enthusiast community.

Reply Parent Score: 2