Closed Bug 448888 Opened 17 years ago Closed 17 years ago

slow page and text zoom

Categories

(Firefox :: General, defect)

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

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: hunteke, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008061017 Firefox/3.0 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008061017 Firefox/3.0 I can't imagine that this hasn't already been reported, but I was unable to find (in a < 5 min search) a summary bug report that matched. Basically, the ability to increase text font size, or more generally enlarge the view of the page, is slow. In FF2 I can hit Ctrl+Plus five or six times before a noticeable wait occurs. In FF3, as soon as I hit Ctrl+Plus (or minus), it takes a couple of seconds before the zoom operation completes. Reproducible: Always Steps to Reproduce: 1. Hit Ctrl+Plus 2. Wait longer time that should be necessary 3. Do it again, if you so desire. Actual Results: The page zoom functionality is slow, taking a noticeable couple of seconds before displaying the page again. Expected Results: Page zoom is *presumably* (from this lay-person's perspective) just a multiplier in a lot of places. This should be near instantaneous. The machine is not the problem, as this is a 2.2 GHz, Core 2 Duo, with 2 gigs ram. Or, put another way, FF2 performs *much* faster on the same hardware. This is an Ubuntu Hardy machine, but I've noticed the same behavior on my girlfriend's WinXP machine. $ uname -a Linux hani 2.6.24-19-generic #1 SMP Fri Jul 11 21:01:46 UTC 2008 x86_64 GNU/Linux $ lsb_release No LSB modules are available.
How bug is this page, can you give an example, and have you tried in Safe Mode?
Example page: http://news.bbc.co.uk/ If I start at the standard Ctrl+0 zoom, then increase the page zoom, I note a second or two to recalculate. (Doing the same in FF2, I don't notice this second delay. Only after the 4th or 5th zoom.) Donning a developer hat: more rigorously, it appears to cache the result, so if I increase to an as yet un-zoomed-to level, the delay is noticeable. If I then decrease and re-increase, it's not near so slow. More example pages: http://www.w3.org/ http://trilug.org/ http://news.google.com/ http://slashdot.org/ http://www.ubuntu.com/ Here are some example pages, which I tested in safe mode: http://en-us.www.mozilla.com/en-US/firefox/3.0/firstrun/ http://www.djangoproject.com/ http://www.mozilla.org/ http://www.ci.chapel-hill.nc.us/ http://news.bbc.co.uk/
Are there any Linux users who _can't_ reproduce this bug? I'm running Firefox 3 on a lot of different Linux boxes, from Slackware to Fedora, both 32- and 64-bit. All have exactly this problem, and it's starting to get on my nerves. It makes Firefox 3 feel a _lot_ slower than Firefox 2. I used to be able to resize by using Ctrl+mouse wheel, but that function is useless now because Firefox will hang for 5-10 seconds while re-rendering the text in a different size. Could the problem lie outside Firefox (like its font rendering library)?
->Haakon Riiser: it seems to be OK on my Archlinux system. But on my Mandriva Cooker, I can indeed reproduce this bug: * https://bugzilla.mozilla.org/show_bug.cgi?id=410365 * https://qa.mandriva.com/show_bug.cgi?id=43396 It seems to be fine for other Mandriva Cooker users. Regards, Shlomi Fish
Are you using the version of Firefox that came with your distros, or are you using the same precompiled version provided by mozilla.org? If you are using the same version, the problem must be with one or more system libraries, right?
->Haakon Riiser: I've tried it with both the distribution-shipped firefox and the pre-compiled binary from mozilla.org, and the problem exists in both. Even on new Unix accounts with a minimalistic window manager. I should note that with 2.0.0.16 (from mozilla.org), it is much better.
Then I assume it's either the font rendering library (whichever library that is), or maybe it's a subsystem that the font rendering library uses to hardware accelerate things. (I don't know enough about the font system in X/Linux to say, so hopefully someone can step in and help us isolate this bug.) By the way, here are the libraries Firefox uses on my Fedora 9 system (which has slow font rendering): ld-2.8.so libatk-1.0.so.0.2209.1 libc-2.8.so libcairo.so.2.17.5 libdl-2.8.so libexpat.so.1.5.2 libfontconfig.so.1.3.0 libfreetype.so.6.3.16 libgcc_s-4.3.0-20080428.so.1 libgdk_pixbuf-2.0.so.0.1200.11 libgdk-x11-2.0.so.0.1200.11 libglib-2.0.so.0.1600.5 libgmodule-2.0.so.0.1600.5 libgobject-2.0.so.0.1600.5 libgtk-x11-2.0.so.0.1200.11 libm-2.8.so libpango-1.0.so.0.2000.4 libpangocairo-1.0.so.0.2000.4 libpangoft2-1.0.so.0.2000.4 libpixman-1.so.0.10.0 libpng12.so.0.29.0 libpthread-2.8.so libselinux.so.1 libstdc++.so.6.0.10 libX11.so.6.2.0 libXau.so.6.0.0 libxcb.so.1.0.0 libxcb-xlib.so.0.0.0 libXcomposite.so.1.0.0 libXcursor.so.1.0.2 libXdmcp.so.6.0.0 libXext.so.6.4.0 libXfixes.so.3.1.0 libXinerama.so.1.0.0 libXi.so.6.0.0 libXrandr.so.2.1.0 libXrender.so.1.3.0 libz.so.1.2.3
Confirming that it exists as well for a mozilla.org copy of Firefox 3: $ wget -c "http://download.mozilla.org/?product=firefox-3.0.1&os=linux&lang=en-US" # closed any currently running instance of FF while waiting # for download $ tar -xf firefox-3.0.1.tar.bz2 $ cd firefox/ $ ./firefox -no-remote -safe-mode # Noted problem still 100% reproducible as described above, # including a 2G increase in ram (4g total now)
I also sorely feel this issue on all Linux installations of Firefox 3 that I've used. These include RHEL 5, and Ubuntu 7.10 and 8.04. All Firefox versions are mozilla.org's versions, on 32bit x86. This happens even on a fresh install with no extensions. Because of this, Firefox 2 was effectively much faster for me than Firefox 3.
I've also noted slow scrolling in FF3 as compared to FF2. I wonder if this is caused by the same or related bugs. A dev will have to confirm or deny this. (If it's not, I'm happy to make a new bug.) A large Slashdot comment page does a good job of highlighting this scroll-performance difference. For example: http://tech.slashdot.org/tech/08/09/14/195203.shtml
I'm not a FF developer, but I don't think it's the same bug. The zoom bug seems to be caused by slow font rendering - if you resize down from one size to another, and back up again using the same zoom steps, the return zoom will be much faster (because the fonts have been cached?). In the scroll scenario, the CPU usage seems to be constant, even when I scroll over the same text over and over. IIRC, there have been filed several bugs for slow scrolling in FF3 - have you compared your problem with those reports?
Fair enough. My thought was one of rendering for scrolling, but your point about the cached "instant" response vs constant CPU usage is a good one. I'll check some of the other bug reports.
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.
I didn't have the situation with circular links - in fact, there are only two symbolic links under /usr/share/fonts on my system: $ find /usr/share/fonts -type l /usr/share/fonts/zh_CN/TrueType/zysong.ttf /usr/share/fonts/zh_TW/TrueType/bsmi00lp.ttf Both of these links refer to regular files.
This bug could be duplicated (or at least related to) of bug #462660 ("Firefox zoom speed depends on number of fonts installed"). Many Linux distribution (unlike Archilinux) install a lot of fonts, by reducing it (e.g. 4000 -> 100) to get a big speed increase with zoom function.
I finally got around to checking if the number of fonts affect the zoom speed. With my default setup, I have 319 fonts (according to fc-list | wc -l). I then removed all font directories from my path, except for one directory that contained a single font. fc-list | wc -l now prints 1. Firefox's zoom is still as slow as when I had 319 fonts. I also confirmed that the bug is still present in the latest Firefox 3.1 beta: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b3pre) Gecko/20081203 Shiretoko/3.1b3pre
I just downloaded the latest trunk build[1]. The issue seems to be gone. It's not an exhaustive test as it's a stock Firefox (from Mozilla), as opposed to Ubuntu-touched version 3.0.5 I'm using now. A data point. [1] http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
If there is something wrong in the Ubunto version, take it up with them. This is WFM for now.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Also works for me in the latest trunk build. Any chance of getting this fix into Firefox 3.1?
If this bug is really fixed in latest build then isn't correct mark it as WORKSFORME, but FIXED. WORKSFORME is for not confirmed bugs. This bug isn't related to Ubuntu Firefox build, see also bug #462660.
In fact, its *not* fixed in any production release or almost-production release. Reference final sentence of comment #16. Neither is it /just/ an Ubuntu bug. Reference comments #3, #6, #8, and #9.
@Kevin, you said the latest trunk (3.2a1pre), is as you said "almost-production" release. All change made there will most likely make it into Firefox 3.2 final (unless they get backed out). @Haakon, we don't know which patch caused this fix, so there is no way of getting it into 3.1 until we do. @Francesco, same as above. This is WFM unless we know what patch has fixed it. I don't, so unless you know (please post it up here so I can see it), this is WFM for now.
Version: unspecified → Trunk
(In reply to comment #22) > @Kevin, you said the latest trunk (3.2a1pre), is as you said > "almost-production" release. All change made there will most likely make it > into Firefox 3.2 final (unless they get backed out). 3.2 is nowhere near production. Anything with an "alpha" tag is a long, long way from a production release. > > @Haakon, we don't know which patch caused this fix, so there is no way of > getting it into 3.1 until we do. I'm not sure if it is related, but we are implementing @font-face support and changing lots of the font rendering code in the wake of that change. This work is targetted at 1.9.1, so it will show up in Firefox 3.1. The bug for that is bug 468218. The way we do things, these changes will show up on trunk first and then move to the 1.9.1 branch. > > @Francesco, same as above. This is WFM unless we know what patch has fixed it. > I don't, so unless you know (please post it up here so I can see it), this is > WFM for now. While this might be fixed on trunk, we do need to try to understand what changed in order to fix it. Can anyone determine a regression range of when the fix landed on trunk? Then we can easily determine which bug needs to land on 1.9.1 from that list. Also, this is obviously not a ubuntu only bug, but it is working on trunk. I'm not sure what to do with the WFM status here. It seems that it was a bit pre-mature, but is correct when thinking about trunk. Reporters, feel free to reopen and target this bug against 1.9.1, if you wish. However, I think a more useful thing would be to have the regression range for when the bug became fixed on trunk that way we can try to get the fix landed on 1.9.1. Leaving status as-is for now.
I'm happy to do a binary search with a "does it work" test. However, I'm but a noob dev and have yet to successfully compile any Mozilla product. I doubt there are nightlies beyond the most recent nightly ... ?
(In reply to comment #24) > I'm happy to do a binary search with a "does it work" test. However, I'm but a > noob dev and have yet to successfully compile any Mozilla product. I doubt > there are nightlies beyond the most recent nightly ... ? Oh no, we keep them all, specifically for this reason. The current trunk nightlies are here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ That will get you back to the beginning of december, which is probably sufficient, as we branched in late November. But should you need nightlies further back, they can be found in the 2008/ directory from there: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/ Thanks for helping us out with the regression range, I really appreciate it!
Does the following report help? 2008-10-23-02-tracemonkey - slow/bug 2008-11-01-02-tracemonkey - slow/bug 2008-11-05-02-tracemonkey - slow/bug 2008-11-06-02-tracemonkey - slow/bug 2008-11-08-02-tracemonkey - fast 2008-11-10-02-tracemonkey - fast 2008-11-14-04-mozilla1.9.0 - slow/bug 2008-11-17-02-tracemonkey - fast 2008-11-20-02-tracemonkey - fast 2008-11-21-04-mozilla1.9.0 - slow/bug 2008-11-22-02-mozilla-1.9.1 - fast 2008-11-30-02-mozilla-1.9.1 - fast 2008-12-05-14-mozilla-1.9.1 - fast
9621d305de92 2008-11-07 09:39 +1300 Karl Tomlinson - b=bug 449356 font selection through Mozilla's PangoFcFontMap, r=roc Maybe this change fix the problem?
I hope that change is it, because I'm having a hard time finding the bug now. It's not there as early as 2008-12-07, and when I got to the 2008/11/ or 2008/12/ webdirs, there are no (or very few) x86_64 Linux builds.
(In reply to comment #25) > Thanks for helping us out with the regression range, I really appreciate it! Done, in comment #26. May this bug be marked as "FIXED"? And what about backport to fix the problem in current branch?
You need to log in before you can comment on or make changes to this bug.