Closed Bug 410365 Opened 17 years ago Closed 14 years ago

Text zoom is extremely slow on ubuntu

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
2.0 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: skroops, Unassigned)

References

(
URL
)

Details

(Whiteboard: [CLOSEME 2010-07-30]) 

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.11) Gecko/20071204 Ubuntu/7.10 (gutsy) Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.11) Gecko/20071204 Ubuntu/7.10 (gutsy) Firefox/2.0.0.11

Whenever I zoom with ctrl+mousewheel in firefox, the system hangs. If I zoom say 4 or 5 clicks on the wheel, the window will gray out and it takes about 20 seconds to catch up. Same problem if I hit ctrl++ or ctrl+- more than 3 times in a row. No other significant speed problems on the whole system.  It just slows down when zooming in firefox.  The amount of text on a page affects the problem, i.e. zooming www.google.com is faster than en.wikipedia.org, however google is also very slow.  No problems on same system with windows firefox.  Same problem on other PC with ubuntu 7.10.


Reproducible: Always

Steps to Reproduce:
1. Zoom with mouse wheel to a much larger or smaller size than default to cause heavy slowdown.
2. Zoom with ctrl++ or ctrl-- 1 time to cause minor slowdown
3. Zoom with ctrl++ or ctrl-- 3 times or more to cause increasingly drastic slowdown.
Actual Results:  
Depending on the amount of zoom, system slows down more and more.

Expected Results:  
The zoom should be very quick, anything less than 4 or 5 zoom increments quickly should not be noticably slower.  Should work the same as windows firefox.

Running on a P4 2.0Ghz with 1024 MB ram and ATI proprietary drivers.
Also tested on a Athlon X64 3800+ with 1024 MB ram and Nvidia proprietary drivers.
Summary: Text zoom is extremely slow on amd64 ubuntu → Text zoom is extremely slow on ubuntu
Hi,

>> the window will gray out and it takes about 20 seconds to catch up.

cannot confirm here with a SiS661 on board graphic chip (ff 3.0b3pre), but thats not the point. I suggest testing if the problem also occurs with the open source drivers. after all ff developers are open source developers and might be more into working with completely oss accessible systems rather then having to deal with a black box at one point.

Facing the same problem on an Acer Laptop:
AMD Athlon X2 (1.8ghz)
NVidia GeForce 7000M
1 GB RAM
Firefox Beta5 (32bit Ubuntu 8.04) kernel 2.6.24
Same problem here. Ubuntu 8.04 Hardy Heron with nvidia Gforce Go 7600 proprietary drivers loaded v169.12
Isn't that related to Pango? Try with:

MOZ_DISABLE_PANGO=1 firefox

and this should help.
Nope, it didn't help.
Can confirm that 
MOZ_DISABLE_PANGO=1 firefox
does not make any noticeable difference.
Hello!

Same here

I'm running Firefox3 RC1

Kubuntu 7.10
Intel Core 2 Duo...
Intel GM965
Intel Graphics X3100

disabling Pango doesn't help.. have no idea why it is so.. I'm suffering from this from a long time ago.. 

please please.. fix it!

Must also say that I've tried to run in safe-mode (with resetting all the settings, prefs etc. and disabling all the plugins). No difference.
Same problem here but only on one of my machines.

Both machines have these in common:

Firefox 3 beta 5
Ubuntu 8.04 (Hardy)
Kernal Linux 2.6.24-18-generic
Gnome 2.22.2
2 gigabytes RAM

and the differences:

Machine on which zooming is ok (a Dell Precision M90 laoptop for work):

Intel Core Due 2500
nVidia Quadro FX 2500M

Mazhine on which zooming is very, VERY slow (my rather old home pc):

AMD Athlon 64 X2 4200+
ATI X800

If anyone working on this error would liek mroe ifnormation about my configurations I'd be more than willing to provide it, if they can tell me how to find it.
On the Firefox3 RC2 this issue was partially fixed. It is now a bit faster.
(btw, no disk activity while zooming)

But still slow.
I'm seeing this in both the Minefield nightly and the Gran Paradiso nightly. Resizing a page the first time lags badly, works fine after that.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a1pre) Gecko/2008071602 Minefield/3.1a1pre
Yes, when I compare the resize speed on Linux and Windows, there is a huge difference.

Windows computer - Duron 700mhz, 256MB RAM, 80gb HDD, GeForce 5200MX. Speed: excellent

Linux computer - Intel Core2Duo 2.53Ghz (3mb cache), 2gb RAM, GeForce 8600GT. Speed: slow

How can this be that this Windows computer is MUCH slower than linux one, but Firefox works a lot faster there. I think FF team should either dump cairo/pango or make some patches, because these two libs are pretty slow (like GTK on Windows compared to native windows widgets. GTK looks the same, but is much slower on the same machine).
Happens on 3 of my computers all using the ati proprietary driver. I can't seem to use the open source drivers for my cards yet, but I can try the live cd on other computers. It sounds like the problem may be linked to the proprietary drivers (see comment #1.) If anyone sees this problem while using the open source drivers please say so.
I have noticed 100% cpu load during the zoom operation.
I also wonder if this issue is related to the System monitor graph consuming too much cpu: https://bugs.launchpad.net/ubuntu/+source/gnome-system-monitor/+bug/187383
I've noticed this only effect web pages - if Firefox is just viewing a picture then the zoom is fine.  I was going to try this by putting a picture in an html page which contains no text, just a picture but I haven't yet, but you can test this with a gioogle image search.  The page the image is in will be slow to zoom, but just displaying the picture the zoom will be fine.
I've reported this problem here:

https://qa.mandriva.com/show_bug.cgi?id=43396

It seems to be a fontconfig issue from what I tested, but I don't know exactly what causes it. I tried to trim down my fonts' list, but to no avail. It doesn't happen on Archlinux where the resize is fine.

Regards,

-- Shlomi Fish
I can confirm that even when it worked bad on Fedora 9 for me, it works fine on Gentoo at this moment (same machine). Both systems were 64-bit (Firefox - the one downloaded from Mozilla, 32-bit).
Not fixed in Intrepid.
I was able to make the problem much less severe by doing this:

https://qa.mandriva.com/show_bug.cgi?id=43956#c11

Those who suffer from this bug may wish to try it.
But that doesn't explain why Firefox starts behaving normally after few seconds of zooming in and out. Also, even though it works fine for me on Gentoo, I think it's only because Gentoo is just faster than Fedora. I've opened google.com and tried to zoom. It was pretty fast, but second zoom was just smooth.

Also, it's sad to tell, Firefox 3.0.2 under WINE is __FASTER__ than native Firefox 3.0.2 for Linux (I am not speaking about interface, but Google page resizing, it does not wait, it behaves just like Linux version after few zooms).

Also, Firefox 3 under Wine remembers Window position and size.
Ok, I figured out what is going on. Firefox isn't slow on Linux - it is usually slow on Linux because of large number of fonts installed.

Many Linux distributions come with lots of fonts for different languages - just try to remove them and Firefox will start working properly. It seems that the Firefox performance depends on number of fonts installed (I had lots of fonts installed by default on Fedora 10 Beta). So it's not Linux-specific, it's a global bug. I'll try to test it tomorrow (I'll install lots of fonts on Windows machine to check it out).

This is the reason why it worked fine on Gentoo (user manually installs the fonts, so I had only few installed). I believe this is the reason why it does work properly on Archlinux.

It seems that on every resize step Firefox loads a font again and again. After few resizes the fonts are cached, so there is no delay. When it loads a font it walks through all fonts and then picks up correct one. I've noticed that some very complicated sites are resizing faster than plain google site (and I believe that this is because CSS sets only one font-family for webpage fonts). I think "platform" should be changed to "All".

After removing fonts, Firefox works a lot better. I still have 173 font files in /usr/share/fonts, but had about 500 before removing. Windows usually got ~50 (few fonts with variants like bold). Can someone confirm this?
Great job!!!

Your reasons seem to be realistic.
I've looked at my /usr/share/fonts
and found several folders with other subfolders. There are really many fonts.

Since I'm an avergae Linux user I didn't dare to remove them and test without afraid of crashing.

I hope this will be fixed soon.

Thank you!
I've removed them by using Fedora's yum application.

yum remove abyssinica-fonts m17n-db-tamil m17n-db-bengali un-core-fonts-dotum VLGothic-fonts lklug-fonts lohit-fonts-oriya

Had some more, but I can't remember which ones. If this is the reason, it seems it cannot be fixed quickly, because FF devs would have to change the way Firefox renders fonts...
I can confirm this bug isn't related to video drivers but to number of fonts installed, as reported by Tomasz Sałaciński. I had 4600 fonts installed in /usr/share/fonts, and now reducing it to 300 I get a great speed increase. Please, change issue title or open a new bug report. And thank you Tomasz.
I've posted a new bug to give attention to Mozilla devs: bug 462660. Please, go there and confirm it.
I have this same problem, does the video card driver have anything to do with firefox zoom performance with the ctrl-scroll feature?

I'm using the proprietary driver: NVIDIA accelerated graphics driver (version 177), but my windows XP machine has the same performance problem with ctrl-scroll zoom.

I find that I like to zoom almost every page I come across. Does anyone know of a firefox setting that will pre-zoom every page x-times without having to manually zoom each time?
Is it still reproducebile in Firefox 3.5? Anyone can confirm it isn't and then close this bug?
It is only a bit better with Firefox 3.5, but it is still much slower than Firefox on windows, and other browsers on Linux. (Opera, Chromium tested)

Tested On,
Acer Aspire 4520
Ubuntu Jaunty 9.04
Kernel: 2.6.28-13 Generic
1 GB Ram
Total Fonts Installed: 70 only
It is a lot faster for me (maybe because my zoom speed was so slow before upgrade). I can confirm that Windows version works smoother, but right now browsing is convenient on Linux too.

Actually zoom speed should be increased, it's very slow especially compared to Opera. But as far as I know almost every other performance issue is gone.
Yes it's faster in 3.5 this bug can be closed imho.

This can be even faster.. still waiting. but much much better in 3.5.
Works fine for me on Ubuntu Jaunty, recommend this bug gets marked "FIXED".

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1) Gecko/20090701 Ubuntu/9.04 (jaunty) Shiretoko/3.5
Agreed, much better in 3.5.  Still slower than Windows though.
As I tested Firefox 3.6 - it works even faster. IMHO this bug should be closed as fixed. I've tested Webkit on Win32 and Linux, Gecko on Win32 and Linux, Opera 10 beta 2 on Win32 and Linux and Internet Explorer 7 and 8.

Maybe this is my configuration (tested on three computers) but right now IMHO nothing can beat Gecko - from slowest it became the fastest engine I've ever used.
skroops, close please.
This bug was originally reported on Firefox 2.x or older, which is no longer supported and will not be receiving any more updates. I strongly suggest that you update to Firefox 3.6.6 or later, update your plugins (flash, adobe, etc.), and retest in a new profile. If you still see the issue with the updated Firefox, please post here. Otherwise, please close as RESOLVED > WORKSFORME
http://www.mozilla.com
http://support.mozilla.com/kb/Managing+profiles
http://support.mozilla.com/kb/Safe+mode
BTW, retained layers, which will be landing on trunk shortly and will be in Firefox 4 will dramatically increase zoom speeds.
Whiteboard: [CLOSEME 2010-07-30]
Version: unspecified → 2.0 Branch
I'm currently running FF 3.6.6 and it is no longer a problem.
Have not tested newer version of FF but will go with consensus
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.