MASTER - slow scroll with image as background-repeat

Bug #125970 reported by Nicolò Chieffo on 2007-07-14
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
firefox (Ubuntu)
Mozilla Bugs
firefox-3.0 (Ubuntu)
firefox-granparadiso (Ubuntu)
xorg (Ubuntu)

Bug Description

Binary package hint: firefox


I've found that scrolling is slow in all sites (comparing to windows), but really slower in sites where there is a static image that does not move when I scroll
site example:

I think that this .css is the cause of the problem
body { background-color: #fff;
background-image: url("images/rubric/gradient.gif");
background-attachment: fixed;
background-position: bottom;
background-repeat: repeat-x; }

this problem is empathized when using compiz.
The problem is present with both radeon and nvidia video cards, even when compiz is disabled

This problem is less invasive if using firefox downloaded from (without ubuntu patches) or swiftfox, but it is still present
Scrolling in windows XP is really faster (when I say really I mean at least 10x in the starcraft site, which is the site that has most slowdown problems), even in sites that does not have a background image

Other tests
epiphany 2.19.5-0ubuntu1: same slowdown as firefox
konqueror 3.5.7-1ubuntu10: much more reactive in and normal sites, but slower in

WFM Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030408

Product should be PHOENIX

WFM Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4a) Gecko/20030408 Phoenix/0.5+
Athlon XP1600+ nForce

Well, I though it was a well-known problem, and I've seen it lots of times. I've
removed the fixed background on my website because of this. For me it's a dupe
of bug 90198.

WFM Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030408
Celeron 333 MHz 96 MB Ram, SiS6326 Graphicscard (8 MB)

With this computer I see a difference in scroll speed, but speed is reasonable
fast in both cases. Both computers 800x600. But with both computers I had to
wait long, till all images from Phoenix Help were loaded.
On the testpage I didn´t see a remarkable effect, wouldn´t have noticed

Actaully, for this particular page, it's a WFM (build 2003040910 on Mac OS X
10.2.4), even on my old 300 MHz iBook. The smooth-scrolling is the biggest
contributing factor. We've progressed immensily the last few months.

BTW: most of the urls in bug 90198 are about a fixed background. This bug is
about fixed positioning, and I think it's a dupe of another bug.

For reference:
Athlon 800Mhz (384MB PC100)
GeForce4 Ti 4400 (128MB DDR)

After seeing the WFM comments, I checked the pages again to see if I was crazy.
I got no significant slowdown, and couldn't figure out why. I think I'm getting
there, though. I've done some more testing, and am downloading a mozilla nightly
to see if this is phoenix-specific.

I am able to reproduce the problem by having certain other programs running
(though idle) at the same time as Phoenix. It seems to be a very binary thing;
either scrolling is seriously hampered, or it isn't. (And, well, yes--fixed
elements slow down a page even when this problem isn't present, but not by
nearly as much.) This reminds me of comments 18-22 or so in Bug 90198.

The program that causes the slowdown, on my machine, is a java-based text editor
(jEdit; Any time it is open, the problem is present on
pages with fixed elements. Other pages seem unaffected, but that may be just
because of the inherent performance differences.

Additionally, (and this is strange) if I set the windows Task Manager to display
as 'always on top', and leave it over a page without fixed elements, that page
suffers from the same performance drop that pages with fixed elements do. This
seems to be less true of Winamp and the windows CD player, perhaps because they
take up less screen-space. That seems like it could be windows-specific; has
anyone encountered this in unix/linux?

Additionally, can anyone recommend some other java-based GUI programs to test

just adding that I've confirmed I run into the problem in Mozilla as well as

I see the choppy scrolling, but that happends with and without the menu being
fixed. Also blocking the images (remove background image) doesnt help. It gets
choppy in the top, where all the thumbnails are.

I've noticed that as well, but it's a different issue. If you are encountering
this, it'll be pretty drastic, and bad even down below the big image grid.

Marking NEW to get this somewhere. I couldn´t find a bug that explicitly deals
with fixed elements in general. I´m adding a dependency to bug 90198 which is
about fixed backgrounds.
Furthermore I believe this should block Bug 198964 ("Enable/disable smooth
scroll by default") since this bug is much worse when smooth scrolling is enabled.

Created an attachment (id=121395)
a testcase which let you choose 'fast scolling mode' and 'slow scrolling mode'

I have discovered offscreen fixed div will make scrolling slow, however, if the
fixed div is in the document entirely, scolling speed is acceptable.

I hope this helps :)

On Firebird the fixed div will overpaint the scrollbar everytime the document is
scrolled, furthermore, I have tried to change it to offset to -10px to avoid
scrollbar repaint (which may account for scrolling slowness), but the scrolling
is still slow.

The slowdown is more apparent when you use 'up' or 'down' cursor key on your
keyboard to scroll :)

That is extremely helpful. Thanks!

roc+moz: I have just tested my testcase in (not so) nightly mozilla build on
Linux, and it seems that the problem is not as apparent, if there is any slow
downs at all, as my gtk2 phoenix build (which uses XP scrollbar...), so I
suspect my testcase is deomonstrating another problem other than general
slowness (or I have broken my source tree).

roc+moz: I have tried my testcase on Phoenix GTK2, Phoenix GTK nightly
(20030423) and Mozilla nightly (mentioned in prev. comment, 2003042307).

1. my testcase
1a Phoenix GTK2: slows down (as exptected), red div overpaint on XP scrollbar.
1b Phoenix nightly (GTK): no slow down, however, red div still overpaint on GTK
scroll bar
1c Mozilla: no apperant scrolling slowdown, no red div overpaint, works perfectly.

2. texturizer theme page:
2a,b,c all three browser exhibits same problems:
1) it takes me a few clicks to get the menu locked.
2) mouse wheel is unable to scroll the page after the menu is locked (by 2+
clicks), until I have clicked empty area on document.
3) scrolling is slow, jerky, blah blah blah... after the menu has been locked.

-> Chu: Thanks so much for doing the heavy lifting here! I feel very bad about
abandoning the bug for two weeks...

Based on comment 15, I've downloaded mozilla 1.4a (Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.4a) Gecko/200304010) and tested the attachment in it
as well as phoenix:

On my system (was Win2k, now WinXP), /both/ Firebird and Navigator have /both/
the slowdown and the scrollbar overpaint. Perhaps this is a windows/linux
difference somewhere in the lower level stuff?

Created an attachment (id=121753)
similar patch isolating position:fixed from the scrollbar overdraw

Actually, now that I'm looking at this, there seem to be as many as three bugs here:

(1) Like in the bug's name, any pages with fixed elements scroll noticeably
slower than those without such elements. The second patch illustrates only this
bug. Additionally, on Windows2k/XP, I can duplicate this behavior on a page
without fixed elements (such as either attachment in 'fast' mode) by having an
'always on top' window overlapping the browser window. Can this be checked in linux?

(2) In the case that such a fixed element is displayed partially offscreen, two
things happen: (i) scrolling slows drastically, and (ii) the element can
overdraw the scrollbar.

(3) This is the bug I was initially encountering/reporting, and can no longer
reproduce. While running the program jEdit 4.01, mozilla/phoenix were scrolling
at speeds of around 5-6 px/second on pages with fixed elements. If I encounter
this again, I'll make a new, more specifically targeted (and better tested!) bug.

As it stands, I think it'd be best to focus on the first of these here, perhaps
make a new bug for the second if it's unrelated, and drop the third entirely.

Don't we already have a bug for point 2?!

just adding some comments based on my experience in the past few weeks.

In both Mozilla and Firebird, scrolling-speed is reduced on Windows platforms if
either of the following conditions exist:

1) The page contains a fixed element.
2) Another window (set in 'always on top') is partially or wholly on top of the
browser window. (Winamp, Task Manager, etc...)

The more fixed elements present (including windows 'on top' of the browser), the
more noticeable this slowdown is.

Other comments:

I'm still thinking this may be specific to windows, and perhaps how mozilla
paints itself under the OS. Can anyone cross-test this between windows/linux or
windows/OS X? I don't really have access to linux machines or non-uberfast OS X

I've tried to see how IE behaves, but can't get mine to display anything other
than backgrounds as fixed. Having windows on top of the IE window doesn't seem
to affect its scrolling speed at all, though.

Recent builds of Firebird slow down _much_ less than before. Neither test case
produces a noticeable slowdown at all on my Athlon 500. The texturizer page is
only barely choppy. What changed?

Just switched to the 25 August nightly of Firebird (from 6.1) and noticed that
things have slowed back down. A lot.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030825 Mozilla
on Windows 2000
Athlon XP 2100

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030825
Mozilla Firebird/0.6.1+/jtalkington-nightly
Power Mac G4
Dual processor system.

Anyway... this shows up both on Windows and OS X, so I'm betting Linux/Unix have
it too. Curiously, though, on Mac OS, having transparent or hovering windows
doesn't have much to do with it.

Created an attachment (id=133309)
shows various scrolling speeds/states

Per comment 19, I looked for other bugs for chu alan's test case and turned up
bug 186696 and bug 183495, but those both seem to focus on the scrollbar paint,
rather than the slowdown. I've made a new bug 222198 for this problem.

I'm adding an attachment to this bug allowing tests for scrolling normal,
fixed, and the above case where fixed elements are too big. Performance tests
for this page follow.

Created an attachment (id=133310)
shows performance differences for fixed/non-fixed scrolling

For this bug, I ran some performance tests to show better what I'm talking
about. While the slowdown on account of fixed elements (or a hovering window)
is hard to notice on my now fast machine, the difference in CPU use (and thus
for the user on slower machines) is very drastic! Other browsers do this much
more gracefully, so something's probably wrong.

Just downloaded Mozilla 1.5 and Firebird 0.7, and suddenly this is WFM -- CPU
use in all cases is below 10%, and scrolling's beautiful (apart from the
scrollbar overpaint).

The 1.5 Release notes said something about fixing windows GDI paint problems.
Maybe that's what this problem was? That'd make sense given the fact that having
a non-mozilla window hovering over the mozilla window caused the same problem.
What bug was that?

before closing this bug (and other related bugs), please have somebody check
other platforms as well

BTW from my distant memory, slow down occurs on GTK/Linux as well...

Definitely not WFM! Scrolling is still quite slow for me on pages with fixed
elements. The attachment (id=133309) (shows various scrolling speeds/states) is
no different between the "fixed menu" and "huge fixed menu" however.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031017
Firebird/0.7+ (aebrahim)

The testcase you mentiond is WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.6a) Gecko/20031028
Maybe this is due to graphic driver related problems too?

See Bug 222844 (a dupe i think), where reporter says position fixed is slower
with anti-aliased fonts.

To elaborate on comment #27: I suspect the graphics driver are relevant. I
recently replaced my Kyro-based card (Hercules Prophet 4000XT 32 MB TV-out) with
a GeForce2-based card (MX440; 64 MB) and page rendering generally appears to be
faster on some sites and this bug hardly appears anymore. The testcase scrolls
the same at both speeds. A site that used to be notoriously slow and has become
bearable, albeit still a bit slow, is djst's weblog:
That page might still serve as a useful testcase.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007

*** Bug 222844 has been marked as a duplicate of this bug. *** is very slow here. Firebird 0.7, Windows XP SP1,
PIII 1gh 256ram geforce2.

Perret, the page you mention does not have any element with position:fixed,
thats what this bug is about.

Both the testcases and the URL scrolls are WORKSFORME with Firebird 0.8 branch
build 20040120.

Also WFM with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031218

Mozilla 1.6
Win XP SP1
ATI Radeon 9700 TX
P4 2.53 Ghz

>Perret, the page you mention does not have any element with position:fixed,
>thats what this bug is about.

Actually, it does. Open and and you'll see:

<blockquote>background: White url(images/fond.jpg) no-repeat fixed top

And to make things worst, it's a <a
href=>fixed background</a>.

I'm running "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5)
Gecko/20031007 Firebird/0.7" and scrolling is painfully slow here too.

ps: btw, is the above CSS declaration a valid one? It isn't supposed to be a
"background-attachment: fixed;" somewhere?

I screwed big time in my previous post. Didn't know HTML wasn't supported.


Created an attachment (id=139911)
test demonstrating affect of multiple fixed elements

while working on a page design, i noticed that the number of position:fixed
elements affected the scroll speed, which led me to look up this bug. at first
it seemed like any number more than one would cause a serious slow down, but
after creating and playing with this test, i'm not so sure.

it's based off the previous attached tests, but has 5 elements that can be
locked and unlocked individually. there is a definite deterioration of
performance with multiple fixed elements. the most noticeable way i've found
to test it is to turn on smoothscroll, and use the keyboard arrows one line at
a time. with everything unlocked, it scrolls almost instantly. lock one box,
and it slows down noticeably, but not terribly. each additional locked box
seems to slow it down more. another way to test is to hold down the arrow key
then see how much it "coasts" after you release. with all unlocked it should
stop instantly.

tested in firebird 0.6.1 and 0.7 on windows 2000 sp3, pII 400mhz, 384mb ram,
16mb agp riva tnt. haven't touched a new build since 0.7, so i couldn't
comment on the recent WFMs. my computer is 5 years old now, and i wouldn't be
suprised if any newer computer with sufficient horsepower never saw these

while testing, i also uncovered another issue:
increasing the text size (CTRL +) with fixed boxes destroys performance even
more. oddly, decreasing it doesn't seem to have an effect. not sure if this
is a general thing or something unique to these testcases.

Can anyone reproduce this with a new build and a page that actually uses
position:fixed? - scrolls at about half the
speed of a page without fixed elements. - pick the "fixed menu" stylesheet; scrolls
maybe 25% of normal speed.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040210

My system is fast enough at this point that I don't ever _notice_ encountering
this bug. Apparently I still do, though. On this page, and on the two Greg
mentioned, I tried measuring CPU load while scrolling by holding down the arrow

On this page, CPU use capped at ~10%
On both other pages, CPU use capped at ~80%

Both appear fine from my viewpoint, but obviously mozilla's working a lot harder
when fixed elements are involved.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

Nicolò Chieffo (yelo3) on 2007-08-15
Changed in firefox:
status: New → Confirmed
Changed in firefox:
status: Unknown → New
Changed in firefox:
status: Unknown → New
Nicolò Chieffo (yelo3) on 2007-09-23
description: updated
Nicolò Chieffo (yelo3) on 2007-09-28
Changed in firefox:
status: Confirmed → New
Changed in firefox:
assignee: nobody → mozilla-bugs
importance: Undecided → Low
status: New → Confirmed
Changed in firefox-granparadiso:
assignee: nobody → mozilla-bugs
importance: Undecided → Low
status: New → Incomplete
Changed in xorg:
status: New → Invalid
Changed in firefox:
status: Unknown → Confirmed
Changed in firefox-3.0:
status: Incomplete → Confirmed
Alexander Sack (asac) on 2008-04-29
Changed in firefox:
status: Confirmed → Won't Fix
Changed in firefox:
status: Unknown → Confirmed
Alexander Sack (asac) on 2008-06-02
Changed in firefox:
status: Confirmed → Incomplete
Changed in firefox-3.0:
status: Confirmed → Incomplete
Changed in firefox-granparadiso:
status: New → Invalid
Changed in firefox:
status: Incomplete → Confirmed
Alexander Sack (asac) on 2008-10-23
Changed in firefox-3.0:
assignee: mozilla-bugs → nobody
status: Incomplete → Triaged
249 comments hidden view all 329 comments

For FF 3.1b2:

   Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2

This appears to be finally fixed. I was able to see the problem on all of the test sites; all of them are now MUCH faster. Possibly tracemonkey?

Created an attachment (id=354574)
testcase from real-world intranet with just one fixed div

No, this issue is NOT fixed with FF3.1b2 -- just checked.

Test system: Just upgraded my laptop to openSuSE 11.1 (kernel, xorg-x11-server-7.4-17.3, gnome-desktop-2.24.1-2.16, ATI Mobility Radeon 9600 M10 RV350 with open source driver xorg-x11-driver-video-radeonhd-1.2.3_081202_ed532a7-1.1 (closed source does not work)).

First checked with FF3.0.5, then after reading the updates here with FF3.1b2: Same results.

See attached testcase for our simplified intranet support ticket form. The fixed div in reality contains common text modules for our customer support.

I intentionally left the scrolling content "complex" (table with form elements) to retain a measurable difference:

FF3.0.5 and FF3.1b2:
 Scrolling top-bottom: 7 seconds
 ...with fixed div outside visible window area: 3 seconds

 3 seconds, no matter if the div is visible or not

You may say 7 seconds over 3 is not that much a difference, but a) it feels much worse when scrolling by mouse wheel and b) it adds if you're working on lots of tickets a day. I let two of our support staff members check the FF3 test setup and both said it's unacceptably slow.

Just a thought about all these WFM messages in the bug history: I'd say this is a clue where to seek the bug. It seems to me this bug occurs only with certain graphics drivers. So if the FF3 rendering engine uses other low level functions for scrolling than FF2, i'd suggest testing if these functions perform well with all graphics drivers. Maybe one of these low level functions is rarely used from other applications and thus poorly optimized with some graphics drivers.

gdp77 (gdp77) wrote :

Whoever finds the cause/fix for this bug must be awarded with nobel prize! We are dealing with a major browsing experience degrade and nobody knows how to fix it. A big percentage of linux users are suffering from this bug. I am not sure why mozilla doesn't take it seriously...

Aswarp (aswarp2002) wrote :

I will tell the problems that I am finding with Firefox upon upgrading to Kubuntu Intrepid Ibex. My system is kubuntu 8.10 with all the updates for 2008 applied, Nvidia GF6600 with driver 177, Compiz active, dual core i386 CPU.

Along woth the nasty known bug about right clicking (opens random item), I see that the images for the firefox tabs are not being rendered correctly on the screen. I can see an artifact just below some of them, like a grey line 5 to 10 pixels thick on most of the tabs. When I write in a webpage such as in this launchpad textedit field can not see the cursor, which is very annoying, specially when one does ctrl+arrow_pad_key in order to scroll some words back or forth; I have to write to see where the cursor is located, which can cause some websites operations mistakenly to be activated. Changing from one tab to another is extremely slow, as scrolling is. Whenever I perform any operation in firefox, such as opening a menu option, the program freezes for some seconds, ranging from one to thirty or so, then it performs the operation. I find that I can make it respond sometimes if I invike yakuake console with F12, detracting and retracting it back again seems to cause Firefox to update the window rendering.
All in all, this makes Firefox for me completely useless and really, really enraging when there is work to be done.
I pray the gods to fix all this rubbish once and for all. My theory is that all the good firefox developers have escaped to join Google Chrome...

Ohad Lutzky (lutzky) wrote :

Mathias: Holy crap! Those nvidia-settings made all the difference in the world for me!

---- Stats ----

ohad@rabbit:~$ lspci | grep -i nvidia
01:00.0 VGA compatible controller: nVidia Corporation GeForce 8600GT (rev a1)
ohad@rabbit:~$ cat /proc/cpuinfo | grep 'model name'
model name : Intel(R) Core(TM)2 Duo CPU E7200 @ 2.53GHz
model name : Intel(R) Core(TM)2 Duo CPU E7200 @ 2.53GHz
ohad@rabbit:~$ cat /proc/meminfo | grep '^Mem'
MemTotal: 2071684 kB
MemFree: 228652 kB
ohad@rabbit:~$ glxinfo | grep -i version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.3
OpenGL version string: 2.1.2 NVIDIA 177.80
OpenGL shading language version string: 1.20 NVIDIA via Cg compiler

---- Before ----
Scrolling is sluggish on some sites, especially those heavy with Javascript and images. This would occur whether compiz was on or off. causes Firefox to slow down to a crawl (and to gray out in compiz). Everything would work just fine under windows running within Virtualbox... how embarassing.

ohad@rabbit:~$ nvidia-settings -q glyphcache -q initialpixmapplacement

  Attribute 'GlyphCache' (rabbit:0.0): 0.
    The valid values for 'GlyphCache' are in the range 0 - 1 (inclusive).
    'GlyphCache' can use the following target types: X Screen.

  Attribute 'InitialPixmapPlacement' (rabbit:0.0): 1.
    The valid values for 'InitialPixmapPlacement' are in the range 0 - 4
    'InitialPixmapPlacement' can use the following target types: X Screen.

---- Workaround ----

ohad@rabbit:~$ nvidia-settings -a glyphcache=1

  Attribute 'GlyphCache' (rabbit:0.0) assigned value 1.

ohad@rabbit:~$ nvidia-settings -a initialpixmapplacement=2

  Attribute 'InitialPixmapPlacement' (rabbit:0.0) assigned value 2.

---- After ----

Scrolling is silky smooth, even on

I have no idea what those nvidia-settings mean, or whether they are persistant, but this is definitely worth checking out.

Brian (kravitz-brian) wrote :

Wow! Changing those nvidia-settings fixed the problem for me, too. Great find! Mozilla still needs to address this problem, though.

It did the trick for me too. Thank you very much !
However, it still consumes too much CPU. And scrolling this present page is still too slow...
How can it be that Mozilla hasn't addressed that yet ?

Brian (kravitz-brian) wrote :

After further usage, the nvidia-settings workaround makes other things worse, such as causing my Cairo Dock to crawl when trying to access it, which boosts CPU usage up to 100%. It also resets upon restarting my computer, so the settings would have to somehow be made permanent. Maybe it won't affect other people's CPUs, though.

Roshan George (roshan-george) wrote :

The glyphcache option doesn't seem to exist on Ubuntu 8.04.1:

    $ nvidia-settings -a glyphcache=1

    ERROR: Error parsing assignment 'glyphcache=1' (Unrecognized attribute name).

gdp77 (gdp77) wrote :

The problem exists even on a live CD with no nvidia drivers. The workaround above is not the solution.

Ohad Lutzky (lutzky) wrote :

This problem doesn't occur for me with nvidia-glx-180.

Nenad Radulovic (blueskyniss) wrote :

Because they enabled those settings automatically in 180

*** Bug 474183 has been marked as a duplicate of this bug. ***

gdp77 (gdp77) wrote :

I installed 180.11 from synaptic (ubuntu 8.10) and the problem disappeared!!!


My ati powered laptop though still has the problem.

I wish ATI finds the solution fast

Brian (kravitz-brian) wrote :

Installing 180.11 seems to have worked for me, too. I haven't done extensive testing, but everything seems normal and the performance bug pages scrolls normally. I'm also not having the problems with Cairo dock that I had when I tried the previous workaround.

I still wonder whether the problem is with Nvidia or Mozilla, though.

Tim (aardbeiplantje) wrote :

Can someone check ?

The problem is IMHO 'in firefox', probably cairo, as that does the rendering (?!). On software based X servers the problem doesn't go away. The beta 180.16 drivers from nvidia make the problem dissapear on a PC.. with an NVIDIA card. ATI never had that problem I think, from googling around, and testing at work with ATI boxes on ubuntu 8.04.

SunRays 1g however have an all software X server, and the problem is really bad there. Same on PS3 framebuffer X server. It is escpecially the case when the webpage must be re-rendered for some reason, e.g. on slashdot when going through the comments, the div box at the left on the page stays at the same height. Regular large pages that are static don't have a problem.

Cory Coager (ccoager) wrote :

I have the same issue:

Kubuntu 8.10 64bit
Intel dual core 3.0ghz
8gb ram
nVidia 8400 GS

I tried upgrading nvidia drivers to 180.11, tried disabling all firefox plugins, tried disabling compiz, nothing fixed the problem. One interesting thing to note is I run VMware on the same machine and my Windows VM with firefox runs fine.

Anymore ideas?

I have : Win XP - AMD A64 3800+ - 1 Go - VIA/S3G DeltaChrome IGP

I use a complexe CSS menu on my website ( ) with transparent images.

The scroll is a little slow on Firefox 3.0.7 and it's worse on 3.5b3. On other webbrowser it's not slow.

I think this might have something to do with the nvida video card. On my laptop things scroll fine, and on my desktop it's VERY slow.

Quite possibly. All the machines I use have nVidia cards. If that's the case, then there are two questions to be asked:

1. What do the nVidia drivers do wrong that Firefox depends on?
2. What do other browsers do which dodges the problem?

No, it's not (intrinsically) tied to nVidia. I used to experience this on Matrox G550, am now experiencing it on integrated Intel 865G.

(In reply to comment #160)
> I think this might have something to do with the nvida video card. On my
> laptop things scroll fine, and on my desktop it's VERY slow.

Maybe you laptop with Vista OS
and desktop with XP.

I have information that same browsers renders pages with fixed elements on Vista much faster that on XP.
Maybe it is because new 2D infrastructure in vista.

It's not tied to NVIDIA or Vista... on my Linux computer with NVIDIA graphics card Firefox works very fast, when on Vista computer with NVIDIA card scrolling on such pages is slow. I have 512MB of RAM on my graphics card on Linux computer, and 256MB RAM on Vista computer - maybe this is the issue? I've also noticed, that Firefox's performance drops dramatically when not on default zoom level.

I have lags when page is shrinked or enlarged, but when it's on defualt zoom (CTRL+0) it works perfectly.

I think this bug is tied to slow zooming on Linux and slow performance when zoom level is not at default (

My brother's got 1GiB of VRAM on Vista and he still has this problem at roughly the same level that I have with 256MiB on Linux.

However, I have noticed that Firefox is a lot more sensitive than other browsers to the optimizations for composited desktops on Linux. Konqueror, Opera, and friends work like a charm no matter how video is configured. Firefox's normal operation was sluggish enough to drive me nuts (as its normal state of being) until I finally combined Firefox 3, KWin 4.x compositing, and the tweaks to the nVidia drivers to make compositing work acceptably fast.

On Linux, it's quite likely that our "sensitivity" is because we use cairo's X backend (i.e. depend on Xrender and friends), but other browsers do their rendering in software and just send over complete bitmaps.

(In reply to comment #166)
> On Linux, it's quite likely that our "sensitivity" is because we use cairo's X
> backend (i.e. depend on Xrender and friends), but other browsers do their
> rendering in software and just send over complete bitmaps.

Not true, WebKitGTK does the whole rendering in Cairo too and it's ten times faster than Firefox on Linux (but less stable). Take a look at Midori and compare the rendering speed and zoom speed.

Is it using the cairo X backend or the image backend?

To be honest, I don't know. They just state they have Cairo graphics backend for GTK port, as they state here (under Shared Code Modules, it seems they are using it for image and SVG rendering):

For me, with the newest NVIDIA drivers for Linux, problem doesn't exist if the fixed element is an image(like fixed background). If the fixed element contains some text, it starts to get laggy, and if I resize the page (doesn't matter if I enlarge or shrink it) the scrolling is very laggy.

The problem on Linux starts here:

- resize the page: everything will start working a lot slower
- resize text only: everything is ok
- resizing takes a lot of time (few secs to resize Wikipedia once to a certain level, where Opera can do 7-8 resizes a second to make it look smooth). It seems Firefox doesn't reuse the fonts it loaded, it just loads them on every resize until they'll get cached in memory.

I think the worst problem exists with fonts and Pango backend - Firefox 2 behaved this way, using MOZ_DISABLE_PANGO=1 helped A LOT. But there is no way of disabling this in FF3. I believe this is the source of other bugs (like this one).

Try a nightly trunk build, font caching and text resizing has improved a lot there.

(In reply to comment #170)
> Try a nightly trunk build, font caching and text resizing has improved a lot
> there.

Just tried it. Can't wait for Firefox 3.5!

Works still slower than Opera, but it's like 10 times faster than it was on Firefox 3.1, which had problems resizing plain google site (1-2 sec delay). Now it's SMOOTH. Web surfing is smooth and convenient with new FF. And that's how it's supposed to work. Great job!

I removed all the position:fixed values in the css file and the scrolling on the resulting page is very fast.

Hmm... seems to be fixed in 3.5b4. Even the slowest websites work like a charm now! This version ROCKS and it's superfast in Linux too. Thanks!

I am glad your issue has been resolved, but that makes this bug WORKSFORME. FIXED is only for a bug that has had a known patch checked into the tree, which has not happened in this case.

*** Bug 496786 has been marked as a duplicate of this bug. ***

With Firefox 3.5 R1, in fullscreen mode [F11] the scroll is normal, but with the interface, the scroll is slow.


I just want to tell you that 3.5 version is very fast too. I've tested it on different computer (both with Fedora 11) and it works like a charm.

And for the patch:
I've read somewhere (can't remember where, sorry) that Firefox 3 had issue with artifacts when page was resized, that's why Mozilla Devs tried a workaround that made the pages look great but killed the performance when the page was resized. This seems to be dropped as I can see artifacts again in Firefox 3.5, but it boosted the performance.

Also, resize speed is much faster because of a lot better font caching.

John Vivirito (gnomefreak) wrote :

Is this bug still reproducible in latest version of Firefox in repos

Changed in firefox:
importance: Unknown → Medium scrolls fine on my i915 GPU (thinkpad t420) with FF 16. Is there another test case?

Closing Firefox 3 task. Why is the firefox (Ubuntu) task as Won't Fix marked?

Changed in firefox-3.0 (Ubuntu):
status: Triaged → Incomplete
status: Incomplete → Invalid
Changed in firefox:
status: Confirmed → Unknown
Changed in firefox:
status: Unknown → Confirmed
Displaying first 40 and last 40 comments. View all 329 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.