High CPU usage when zoom is not at default (100% CPU when scrolling, slow)

RESOLVED INCOMPLETE

Status

()

Firefox
General
RESOLVED INCOMPLETE
10 years ago
9 years ago

People

(Reporter: kripkenstein, Unassigned)

Tracking

3.0 Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2

When the zoom is set at the default, scrolling is at normal speed. However, if one zooms out or zooms in (control-+ or control--) then scrolling 'hangs': press pagedown, and you get 100% CPU for around a full second before the action occurs.

Reproducible: Always

Steps to Reproduce:
1. Go to the example website given (but this occurs on lots of sites - that's just an example) 
2. At normal zoom, scroll up/down using pageup/pagedown.
3. Zoom in using control-+, then scroll up/down.
4. Zoom out using control--, control--, then scroll up and down.
Actual Results:  
Pageup/down works fine at normal zoom, but on either zoom in or zoom out the speed is very different, with a noticable 100% CPU usage for a second or so before the actual scroll action occurs.

Expected Results:  
Scrolling with pageup/pagedown should be fairly instantaneous, as it is when zoom is at the default.

Since this occurs in both zoom in and zoom out, it isn't related to the larger page size when zoomed in.

My (very uninformed) guess: Perhaps something to do with image scaling, a new feature in FF3 ?

Comment 1

10 years ago
hi,

i cannot reproduce this with 3.0b3pre. what specs are your system, roughly?
(Reporter)

Comment 2

10 years ago
Hi flibby,

I have an AMD Athlon 3000 and 512MB of RAM. Not the newest system, but it works well on everything else I do. But perhaps if you have a much faster machine then the issue won't be very noticeable to you.

Note that the problem over here isn't swap thrashing, I am far from my memory limit. And it is extremely consistent - normal zoom is fine, all other zoom levels are slow. It is as if there is a difference in how FF3 renders pages at default versus non-default zoom, and the latter is less efficient somehow.

Testing it some more now, I am more certain that the issue is images. On a page with an image only on top (my themed iGoogle homepage), scrolling in the lower text-only area is nice and fast, but scrolling to the uppermost part where the image is has the slowness effect.

Comment 3

10 years ago
>> But perhaps if you have a much faster machine
>> then the issue won't be very noticeable to you.

hi, i have approximately the same system concerning the processor and same level when we talk about RAM.

How long does it hang, when you have clicked or pressed the zoom commands?
Do you use Ati or Nvidia proprietary graphics hardware drivers (report 410365)?
(Reporter)

Comment 4

10 years ago
I'm not using proprietary graphics drivers. I have the open-source "nv" driver in my xorg.conf (and everything works great other than this issue).

Here is another example site: http://ubuntuforums.org/forumdisplay.php?f=11 . On this page, when zooming or scrolling when the zoom is not default, I get almost a 1-second delay, *but only at the top of the page*, where there are more images I guess. Scrolling is fast near the bottom, or when at default zoom.

This *may* be related to report 410365 that you mention. I tested what was mentioned there regarding slowing down even more the farther off from default zoom, and yes, it is slower the more zoom is far from default (doesn't seem quite as slow as described there, however).

I also now notice that the slowness occurs when moving from another tab to the tab with the issue. That is, anything that causes a re-showing of the page (switch tab, scroll, change zoom) causes the issue.

As with the reporter in 410365, I am using Ubuntu 7.10. I am however on open-source drivers (for NVidia hardware, FX5200) and the reporter there is on ATI proprietary.

Comment 5

10 years ago
I can confirm your observations with the ubuntuforums.org site and also that this occurs when switching tabs. I use the Gnome Windowmanager, which means that most of the 512 MB is available to ff, and i would say that the 1 sec is the maximum delay, rather less then that. I also observe a processor peak. Consequently whenever i zoom in or out i come to realize that my computer does have a fan. All in all i can live with it.
(Reporter)

Comment 6

10 years ago
Yes, this is livable, I guess. But it is disappointing that FF3 performs noticeably less well than FF2...

Comment 7

10 years ago
It happens for me, too. Scrolling OGame is a lot slower if the webpage size is not at the default.

Disabling image zoom fixes the problem.

Comment 8

10 years ago
same for me for some websites (with really long pages)
examples:
http://ajaxian.com/
http://cameronmoll.com/

doesn't hangs here but the scroll is really laggy

Comment 9

10 years ago
Running FF3RC2 on Fedora9 with NVIDIA Driver and CompizFusion enabled. I confirm that the scrolling is very slow and Xorg goes very high on CPU. I have also noticed that in general Xorg goes high on CPU whenever a page is scrolled from Firefox3.

Comment 10

9 years ago
Do you still see this problem?  ... Using current version of FF (3.0.4), or 3.1 beta - beta 1 at http://www.mozilla.com/en-US/firefox/3.1b1/releasenotes/ ... or beta 2 available soon 

If you no longer see the problem please close the bug.
Whiteboard: closeme 2008-12-10
@Reporter, we have not heard back from you in a while, so I am closing this bug as INCOMPLETE. You can reopen this bug if more information becomes available. Some helpful information you can provide us is found at http://quality.mozilla.org/bug-writing-guidelines. You should also use a recent version of Firefox, from http://www.getfirefox.com.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
Whiteboard: closeme 2008-12-10
Version: unspecified → 3.0 Branch
You need to log in before you can comment on or make changes to this bug.