Closed Bug 490563 Opened 16 years ago Closed 3 years ago

SLOW Javascript/Ajax performance with Firefox 3.0/3.5 in Linux with NVIDIA drivers

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: u308343, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4

Running: Ubuntu 8.10 & 9.04, NVIDIA GeForce 8600GT, and NVIDIA 180 series (newest) graphics drivers. Also running Compiz-fusion built into Ubuntu.

Problem:  Lots of websites that seem to use Javascript/Ajax heavy scripts run VERY slow with NVIDIA drivers. This appears to be a Firefox issue because I can run Opera, WebKit based browsers, etc and there is NO issue in Linux. Only Firefox.

Example websites:
http://www.shacknews.com   (during the main image transition to a new one the browser slows to a crawl and wont even scroll)
http://www.slashdot.org   (when scrolling to button the new ajax page reload slows browser down)

Tons of websites have this problem with the Firefox 3.0/3.5 + NVIDIA drivers. Those are just 2 test sites.

I have tried a hack suggested on Ubuntu's bug page(with same bug):
nvidia-settings -a InitialPixmapPlacement=2
But it really does nothing.

There is a long running bug page on Ubuntu's website that could be helpful to devs:
https://bugs.launchpad.net/bugs/223238

Please Help!

Reproducible: Always

Steps to Reproduce:
1. Run Linux with newest NVIDIA 180 drivers
2. Run Compiz-fusion
3. Run Firefox 3.0 or 3.5 with any of the websites listed
Actual Results:  
SLOOOOW performance. Seems to be javascript/AJAX related.

Expected Results:  
Normal fast performance as seen with other web browsers.
Version: unspecified → 3.5 Branch
works for me - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.9) Gecko/2009042113 Ubuntu/9.04 (jaunty) Firefox/3.0.9

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b5pre) Gecko/20090428 Shiretoko/3.5b5pre

I have a nearly identical setup 8600gt, nvidia 180 driver, Compiz-fusion. The given example pages load reasonably fast given their size .5s or so. Similar performance on Windows and other browsers.
It's not a matter of the load times. It's a matter of the javascript running while the pages are loaded. For example (as stated) on the Shacknews example during the transitions of images in the "Top Stories" area slow the web browser to a crawl if you try to scroll during them.

Also on Slashdot where you goto the bottom of the page during its reload (where it loads more of the website) it loads very slow.  MUCH slower than Windows. There are many other websites that have issues too on the Ubuntu bug page for the same issue here:  https://bugs.launchpad.net/bugs/223238
I don't see any issue on Slashdot when using their continuous page besides the obvious reflowing of the document as content gets added. Shacknews has a slight hitch when the transition is animating but nothing severe. When I get a chance I'll enable the nv driver and see if there is any difference.
See also bug 431113.  This one seems to have more information, though.

roc, vlad, any idea what might be up here?
Blocks: 431113
Component: General → GFX: Thebes
Product: Firefox → Core
QA Contact: general → thebes
Version: 3.5 Branch → Trunk
Ok, the linked page mentions that apparently the nvidia drivers in question have some xaa bugs in background tiling...

phinn, can you possibly manage to reduce a web page that's slow for you?  Is the issue, as in the ubuntu bug report, some background image?
Status: UNCONFIRMED → NEW
Ever confirmed: true
It seems to me that these are Xrender issues.

The only thing I'm not sure of is why Webkit-GTK2 based browsers (which use cairo I think) aren't hitting them. Is Webkit-GTK2 using cairo image surfaces for its backbuffer or something?
It's not clear to me that anyone in that thread tried webkit-gtk2...  They tried opera, but I see no mention of webkit-based browsers.  Did I miss it?
Ah, indeed.
(In reply to comment #6)
> It seems to me that these are Xrender issues.
> 
> The only thing I'm not sure of is why Webkit-GTK2 based browsers (which use
> cairo I think) aren't hitting them. Is Webkit-GTK2 using cairo image surfaces
> for its backbuffer or something?

They may be, and we may want to as well if we can get SHM pieces in place and get rid of all the child widgets.  Then we'd just have one surface to render to and would control our speed; we'd lose a bit of speed for things like text on some drivers, but we'd get direct control over all of our rendering.
phinn, possible for you to do the reduced testcase mentioned in comment 5?  Or is that information provided in the other bug?
What is the status on this bug? NVIDIA acknowledged an inefficency on their end which I believe they have applied since then but according to them, fixing firefox would greatly improve performance:
"Thanks for reporting this. I took a look today, and it appears that Firefox is using an enormous pixmap that exceeds the GPU's maximum rendering dimensions, causing software fallbacks. While we will attempt to make it as fast as possible, performance would be greatly improved if Firefox would render using surfaces that fit within the maximum renderable dimensions."
http://www.nvnews.net/vbulletin/showthread.php?t=152295&page=1

As someone else had mentioned before scrolling on this page is very slow: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/550625?comments=all

Given the comments from the NVIDIA developer I zoomed out that page in firefox hoping it would 'fit within the maximum renderable dimensions" and indeed scrolling was smooth again. 

The NVIDIA developer most be right if it works much better by zooming out plus I can see the system load spike very high when it 'defaults to software fallbacks'.
Tyler, thanks.  That's very useful information!

Chances are, not much will happen here until we move to doing our own hardware-accelerated rendering on Linux, which will automatically mean pixmap sizes that the GPU can deal with...
Boris,
    Thanks for the update. Is there an estimated time line for the hardware-accelerated rendering on Linux? This has severely impacted our users experience with zimbra (full functionality is with ajax only) as well as pdf inline rendering, and I just need to know what we are looking at so I can provide appropriate work-arounds for my company.
Tyler, I'm not sure there's a firm timeline for it yet.... certainly order of months, not weeks, at best.
Hardware accelerated on Linux is already there - using cairo on top of xrender - which can be accelerated by hardware if the 2d driver supports it.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.