Extremely sluggish scrolling

[Pascal de Bruijn]

When visiting this site with Firefox (or Epiphany), scrolling slows down to a crawl:

http://nitens.org/taraborelli/latex

I'd like that to be sped up in the future.

[Laubzega (thorgal-wfmh)]

I am not sure if I should file separate bug, but the page at

http://www.mysql.org/listcats.php?menu=21&page_id=9

behaves in exactly the same way, e.g. it is really slow when scrolling, be it by
scrollbar, be it by mouse-wheel.

Linux/i686 - 2001071021

[Bugzilla20071228 (bugzilla20071228)]

I have 2 very similar installs. Both debian potato and both use X3, but one is a
2.4.x kernel and the other a 2.2.x kernel.

Hardwarewise one is a p3-600 and the other a p3-700.

The 2.2.x/p3-700 is fine scrollingwise and the 2.4.x/p3-600 is not. It'll
continue to scroll once I've released the key.

Erm. Not sure what to make of this.

(mozzy version is 2001072408 - but repeatable with 0.9.2)

[Gav-gavncal (gav-gavncal)]

The original URL doesn't seem to be valid any more.

The one given by Miloslaw Smyk on 2001-07-12 appears to be valid.

Scrolling seems fine for me : Duron800, Win98SE, 2001080114.

[Laubzega (thorgal-wfmh)]

I've updated the original URL, because it's moved. Both it and the one I've
attached later still scroll very slowly (Linux/i686 2001080106}.

I think that it is caused by BODY tag definition that in both cases specifies

background-attachment : fixed;

which obviously is more gfx-heavy. Considering much slower gfx speed in Linux
Mozilla, this is probably the reason you're not seeing it under Windows.

[Asa (asa)]

->layout

[Laubzega (thorgal-wfmh)]

BTW, I'm running Athlon@1.1GHz with 640MB of RAM and other pages scroll with
20-80Hz. But these are more like 2-4Hz.

[Karnaze (karnaze)]

->kmcclusk based on comments.

[Xan-masilla (xan-masilla)]

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

[Xan-masilla (xan-masilla)]

Changing summary to something more explicative :)

[Jens-uwe (jens-uwe)]

some nice examples which shows the problem with fixed background are:
http://www.webstandards.org/resources.html
http://www.meyerweb.com/eric/css/edge/complexspiral/demo.html

(taken from bug 100575)

[Xan-masilla (xan-masilla)]

Changing summary to something more explicative :)

[Bzbarsky (bzbarsky)]

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

[Jens-uwe (jens-uwe)]

now that the fix for bug 98252 was checked in, the page scrolls pretty fast for
me. Is it still a problem for others?

[Bugzilla20071228 (bugzilla20071228)]

*puts his hand up*

Not sure how bad it was before but it scrolls now, but still slowly. Even with
the small scrollspace I have I can see it. Not only that but it doesn't keep up
with the keyrepeats either. in a bad way.

[Laubzega (thorgal-wfmh)]

Yup, it's as slow as it was. Just checked with 2001092821.

[Laubzega (thorgal-wfmh)]

Funny thing. I've just tested it on my laptop which is much slower than the
desktop machine (i.e. Mobile Celeron 600 vs. Athlon 1.1 and ATI Rage Mobility
128 vs. Matrox G400), but here "slow" pages are scrolling quickly and some (but
not all) things in Mozilla certainly seem to be snappier. Either something has
changed in the last few days (doubtful), or there is some dependency on a
version of kernel/xserver/whatever. As soon as I regain access to my desktop
(two days?) I'll try to narrow it down.

[Xan-masilla (xan-masilla)]

mighty people of bugzilla, I suspect this is a dupe of 69169, but both bugs are
assigned to Kevin. I've posted a comment in 69169, so let's wait and see.

[Laubzega (thorgal-wfmh)]

Ok, I finally found time to conduct some more extensive testing (re: my comments
two messages above).

1. Installing kernel 2.4.12 on the laptop did not make mozilla slower at all.
2. Also X is the same on both machines now - no change in speed.
3. What made the difference, was the depth of the screen: the laptop was using 1
6bpp, while desktop was 24/32bpp. Switching to 16bpp on the desktop made these
slow pages fly (ok, they are still a bit slower than normal ones, but this is
hardly noticeable).

But there is more to it. I investigated my XF86Config-4 file and found that it
contained settings to handle 32bpp mode properly on Matrox MGA400, namely the
DefaultFBBpp and DefaultColorDepth had different values. It seems to be no
longer necessary, so I set them both to 24 and voila, I have fast
scrolling/redrawing Mozilla AND true color.

At least for me, this bug is WFM.

[Kazhik (kazhik)]

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

[Laubzega (thorgal-wfmh)]

Ok, not so fast. After using the settings described in my 2001-11-05 comment for
some time, I've to say that this is still an open problem, although now I
understand it more clearly.

First, this has nothing to do with Layout component, but rather with ImageLib
and that's why I'm putting Stuart on a CC: list.

The situation now is like follows: right after launch Mozilla is scrolling very
fast, the window is refreshed quickly after switching from another desktop or
deminimization. The URLs listed in this bug and in its dupes are behaving very
fluently, just as I've described before).

However, as I open more pages, tabs and windows, there comes a moment when
everything graphics-intensive (like pages with fixed background or the mailer)
gets very slow. This is not something gradual -- the problem either is or isn't
there, depending on some threshold of opened pages). Also, with bigger screens,
greater screendepths, active DRI and other videocard-ram consuming things the
threshold is crossed quicker. And once the problem appears, there is no other
way to get back to quick scrolling than restarting Mozilla (sporadically even
that doesn't help, which I assume has something to do with other apps using gfx
intensively).

All this makes me think that this "threshold" is actually the point where
offscreen pixmap allocations can no longer be made in gfx-card memory and some
of them (or maybe even the backbuffer discussed in bug #95952, 2nd comment) end
up being transferred over AGP repeatedly. This led me to think that the problem
may disappear with introduction of less wasteful pixmap allocation (again, as
described in bug #95952). This however was not the case - everything behaves
more or less the same after the bug was fixed.

Now, the problem may also be due to a bug in the xserver I'm using. I've XFree86
version: 4.1.0.1 and Matrox G400/32MB (running 1440x1080x24), while my laptop
that never shows any problems in this area has the exact same version of
XFree86, but gfx chip inside it is ATI Rage Mobility 128/8MB (running 1024x768x16).

I (very cautiously) suggest that something may still be wrong with offscreen
pixmap allocations and caching them for future reuse. Opinions?

[Thorsten-enabled (thorsten-enabled)]

This "slow scrolling" problem not only appears with fixed backgrounds, but with
every page fixed elements appear.

Try out scrolling the W3C-example of a fixed Menu:
   http://www.w3.org/Style/Examples/007/menus.html

or the other way round - move or resize the frame on
   http://www.cross-browser.com/examples/drag3.html

I've tested this pages in different browsers (IE6, Opera 6, Konqueror) on Linux
and W2k - and they all work much smoother than mozilla 0.97.

(OK :-) IE doesn't get the W3C-example)

Greetings Thorsten

[Bzbarsky (bzbarsky)]

Thorsten, are you testing 0.9.7 on Linux or windows? If windows, you are likely
seeing bug 98252, which was not fixed on windows till after 0.9.7 was released....

[Thorsten-enabled (thorsten-enabled)]

Boris,

you're right. The extremly slow scrolling problem only occurs in the windows
version (bug 98252).

With Linux, mozilla isn't as fast/smooth as Opera or IE under Win, but it at
leasr is much faster than the Win-version.
And this can partially be blamed on the slower XServer.

THX Thorsten

[Jonasj-qio (jonasj-qio)]

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

[Kmcclusk (kmcclusk)]

Bulk moving Mozilla1.01 bugs to future-P1. I will pull from the future-P1 list
to schedule bugs for post Mozilla1.0 milestones

[Spam-minneboken (spam-minneboken)]

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

[Janzert-haskincentral (janzert-haskincentral)]

The last two dups (bug 122423 and bug 126645) were both reported against windows
2000. The one before that (bug 69169) was against Mac OS 8.5. Updating platform,
OS to all.

[Jmdesp (jmdesp)]

Built 2002032708, NT4

I've found another page that displays this : http://webnouveau.net/

This page used to be painfully slow with a night build from 10 days ago.

Now it's a lot faster, and may look acceptable at first look, but if the
"background-attachment: fixed; " attribute is removed from the CSS, the
difference in scrolling speed is still huge.

[Daten-dnetc (daten-dnetc)]

Using: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417

The scrolling is still slow with fixed background images.
One site I maintain is a good example: http://www.dnetc.org

The CSS properties for the background are:
background: #555 url("psy2.png") fixed;

when 'fixed' is removed the speed and smoothness greatly improves.

The machine last tested on 1.7Ghz P4, running Windows 2000 (w/ SP1)
The same behavior was observed on a 500mhz Athlon running Windows ME,
a 950mhz Athlon (tbird) running Windows 2000 (w/ SP2), and a 500mhz
athlon running Linux 2.4.18 w/ X4.2

I'm pretty confident it's a bug with mozilla related to rendering fixed
backgrounds, as other browsers such as IE and Opera can scroll alot smoother
and more quickly on the same page, hardware/os.

[Andreas-hoefler (andreas-hoefler)]

Another slow scrolling page is http://www.rpgworldcomic.com/ .
It doesn't have a fixed element, but a huge background-image with a
"background-repeat: repeat-x; "-setting via CSS.

The scrolling seems to be a bit faster, if the background-image is not on the
screen on the lower parts of the page.

[Laubzega (thorgal-wfmh)]

Andreas, this bug is about slow scrolling caused by fixed backgrounds. There is
a lot of other slow scrolling bugs, including recently popular bug #102321.
Please see if your comment belongs there.

BTW, the page you mention scrolls quickly for me.

[LohPhat (lohphat)]

Status update: This page WFM on 2002050504 win32 on win2kpro.

[Mozilla-06 (mozilla-06)]

Removing blocker status for bug 91351, as that bug already is blocked by bug
100951 (which this bug blocks).

This still is not really fixed for me using 2002050408 trunk on Win2k on an
Nvidia gForce 2 GTS. When I scroll down by pressing the cursor down key, CPU
time constantly is at about 60 percent on my Athlon 1400.

[Imipak-gmail (imipak-gmail)]

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

[Rainerbielefeldng (rainerbielefeldng)]

Looks not so bad with
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0+) Gecko/20020531
What do you think ?

[Kmcclusk (kmcclusk)]

The following two URL's from this bug are slow scrolling using todays trunk
build on WinXP on 750Mhz AMD machin
http://www.flamenco-world.com/flamenco/autor.html
http://www.go-mono.com/faq.html

The other URL's are either no longer available or seem to be fixed.

[Greg-bugzilla (greg-bugzilla)]

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

[Amar (amar-auto)]

 Scrolling looks normal using todays trunk and branch builds: 2002062808.
I have WIN2K on 500Mhz intel and 128mb memory.
May be this is specific to WINXP.

[Jens-uwe (jens-uwe)]

no, http://www.go-mono.com/faq.html is pretty slow here too (p3-500, Linux,
nVidia TNT2)

[Chrispetersen (chrispetersen)]

Created an attachment (id=90636)
Background image with background-attachment: fixed

Scroll performance suffers with this reduced test case

[Chrispetersen (chrispetersen)]

Created an attachment (id=90639)
Background image with background-attachment: scroll

Same test with background-attachment: scroll

[Vhaarr+bmo (vhaarr+bmo)]

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

[Vhaarr+bmo (vhaarr+bmo)]

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

[Spu (spu)]

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

[Kmcclusk (kmcclusk)]

-> Don. the reduced testcase in comment 41 is slow using 10/16/2002 cvs build on
WinXP.

[Dfj-comcast (dfj-comcast)]

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

[Kriskelvin (kriskelvin)]

The following 4 bugs seem to be related (or duplicates):

bug 90198 - scrolling very slow (fixed background)
bug 172626 - Very slow scrolling unless the background is commented out
bug 176150 - Fixed backgrounds cause horribly slow scrolling
bug 184556 - style rule for fixed background causes lag when text scrolled

[Bugzilla-chucker (bugzilla-chucker)]

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

[Bugzilla-chucker (bugzilla-chucker)]

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

[Bugzilla-chucker (bugzilla-chucker)]

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

[Sfraser-bugs (sfraser-bugs)]

Is this bug specific to Windows, or is it XP? Both testcases scroll OK for me on
Mac OS X.

[Msaavedra-linkline (msaavedra-linkline)]

Simon, I can verify that this problem occurs in Linux. According to comment #30,
this occurs in Windows 2000 and ME as well, not just XP.

[Fondacio (fondacio)]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312

Browsing through the comments, I didn't see anyone mentioning screen resolution
as a factor.

http://www.esn-leiden.nl suffers from the same problem when I visit it at home,
but only at a resolution of 1152*768. When I resize the window and it becomes
smaller or when I visit it elsewhere with lower resolutions, everything is fine.

The test case is horribly slow for me, even when I resize the window.

Could it have to do with fixed backgrounds which are repeated? As far as I can
see, the performance problem only kicks in when the fixed background is drawn
more than once.

[Fondacio (fondacio)]

Even stranger: after resizing the site I mentioned in the previous comment and
maximizing the window again, the performance problem has gone and everything
performs smoothly. This doesn't happen with the testcase though.

Sorry for the extra spam.

[Pm-gustav-medler (pm-gustav-medler)]

Same effect (slow scrolling with the mouse) can be shown at website:
http://www.praxis-wiesbaden.de/start/sitemapfs.html
(Sometimes some navigation around the site is needed to trigger effect.)

Background image is fixed with external CSS stylesheet.

Affected Browsers:
NS7.02 final
Moz.1.21 final
Moz.1.3 final

Affected OS:
WinXpProSp1 german (all browsers)
Knoppix/Linux (Moz. 1.21)

[Junk-jiv (junk-jiv)]

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030408 Phoenix/0.5+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030408 Phoenix/0.5+

I discovered this is the site listed above. To verify this, I've visited several
sites in which a certain element can be set to have a position of either fixed
or relative--in all cases, so far, scrolling performance significantly decreases
when the element has a position of fixed. An easy example case follows:

Reproducible: Always

Steps to Reproduce:
10 Go to http://texturizer.net/phoenix/themes.html
20 Scroll -- speed is normal.
30 Move your mouse over the navigation menu.
40 "Lock Menu" should appear at the top of the menu. Click it.
50 Scroll -- speed is slow, very jerky.
60 Move your mouse over the navigation menu.
70 "Unlock Menu" should appear at the top of the menu. Click it.
80 GOTO 20: REM ^_^

This may be related to Bug 90198, but doesn't quite fit its direction. Bug 98252
also seems like it _could_ be related.

I'm not sure how well I've isolated this, but it seems that on pages including
fixed elements, scrolling is slowed considerably. Smooth-scroll, in particular,
can be very bad. Presently, I've focused on the CSS 'position: fixed' part of
this problem, but especially at the listed URL, there may be other nefarious
things at work.

[Hhschwab (hhschwab)]

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

Product should be PHOENIX

[Hhschwab (hhschwab)]

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

[Jo-hermans (jo-hermans)]

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.

[Roc-ocallahan (roc-ocallahan)]

Scrolling with fixed backgrounds is fundamentally a lot more work than with
static backgrounds. Can you find a browser that does it much faster than we do?

[Sms (sms)]

IE and Konqueror both seem to be faster on my machine running Debian unstable.

[Hrunting (hrunting)]

IE and Konqueror both handle fixed background images just fine with performance
problems. The test cases attached to this bug don't scroll in most normal
browsers (they're just one line), so they're not good examples:

Check out this URL in IE vs. Mozilla (I'm personally using Phoenix)

http://anomaly.hrunting.org/old.html

On my Windows machine, Phoenix (a recent nightly) doesn't even render the
background image. It just sits there sucking down 100% of the CPU. Not sure
if that's fixed in new Mozilla trunk builds, but it was definitely a problem
months ago when I originally looked up this bug (before, though, that
background image rendered).

The other URLs posted in this bug show the same problem.

[Hhschwab (hhschwab)]

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 w3.org testpage I didn´t see a remarkable effect, wouldn´t have noticed
slowness.

[Jo-hermans (jo-hermans)]

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.

[Junk-jiv (junk-jiv)]

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; http://www.jedit.org/). 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
against?

[Junk-jiv (junk-jiv)]

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

[Bugzilla-spray (bugzilla-spray)]

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.

[Junk-jiv (junk-jiv)]

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.

[Laubzega (thorgal-wfmh)]

Robert O'Callahan, please see comment #21. Mozilla sometimes can handle fixed
elements/backgrounds quickly and I am pretty sure it depends on the way it
(indirectly) handles video memory on gfx-board.

[Pm-gustav-medler (pm-gustav-medler)]

Mozilla can sometimes handle such pages with CSS-fixed background, but after
some navigation the 'slow-down-effect' appears. This is everytime reproducable!
It seems to me like a filled graphic buffer or a memory leak.

Config:

WinXpProSp1 de, Moz.1.3 20030312 en-us, iPIII 700 Mhz, 768 Mb Ram, Abit BX,
Matrox Mill G400.

Gustav

[Ian-hixie (ian-hixie)]

This is also incredibly visible with smooth scrolling when trying to scroll:
   http://ln.hixie.ch/?count=1000000

At high resolutions (1600x1200 for instance) it can take several seconds to
scroll down just one page, as you watch it jerk through the frames of the
scrolling animation like a slideshow.

Reassigning to default owner. CCing background and scrolling people.

[Bzbarsky (bzbarsky)]

.

[SteBo (stebo)]

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.

[Holyspirit (holyspirit)]

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 :)

[Holyspirit (holyspirit)]

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 :)

[Roc-ocallahan (roc-ocallahan)]

That is extremely helpful. Thanks!

[Holyspirit (holyspirit)]

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).

[Holyspirit (holyspirit)]

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

result:
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.

[Junk-jiv (junk-jiv)]

-> 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?

[Junk-jiv (junk-jiv)]

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

[Junk-jiv (junk-jiv)]

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.

[Pascalc (pascalc)]

I just created a long text page with a fixed background pattern and measured
time needed to scroll the page with a clockwatch using the down arrow key. I
made 3 versions of the background, one with a PNG image with alpha transparency,
one with the same PNG image without alpha transparency and one with this image
in JPEG format :
-with no-alpha PNG : 12 seconds
-with JPEG : 12 seconds
-with alpha PNG : 18 seconds

I run the test 3 times and always got the same result (+- 0.5s). This is with
build 2003042808 WinXP/768MB Ram, smoothscrolling on.

I ran this test with IE6SP1 : 5 seconds

I see no logical reason why the version with an alpha-blended PNG background
should be slower since the PNG image is applied on the body and there is
therefore no element to be displayed through the transparency.

[Christian Biesinger (cbiesinger)]

>the PNG image is applied on the body and there is
>therefore no element to be displayed through the transparency.

Couldn't <html> have a background, too?

[Pascalc (pascalc)]

that's what I thought too, but if you put background-color:white on <body>, it
doesn't change the timing.

[Pm-gustav-medler (pm-gustav-medler)]

<body background=....> is announced as 'deprecated' by W3C-Org. CSS should be used instead. But slowing down effect does _not_ depend on background is integrated by <body>tag or CSS style sheet.

[Bugzilla-spray (bugzilla-spray)]

Both the testcase and the working url:s scrolls smooooth for me.
Build 2003042708. Can anyone re-test to confirm this?

[Pascalc (pascalc)]

Gustav, setting a background color on body when you use a PNG image with alpha
transparency has the purpose to make sure that no calculation is done to
calculate a transparency based on a background pattern set on the root element
(html). My personal tests indicate that part of the problem in fixed background
scrolling is sometimes related to Mozilla performance with PNG images which have
an alpha channel. The same test with the same PNG image with
background-attachment:scroll shows a big scrolling performance boost.

[Pascalc (pascalc)]

Testcase with a PNG background

With background:scroll

http://pascal.chevrel.free.fr/mozilla/bugzilla/pagelongueTPNG.htm

With background:fixed

http://pascal.chevrel.free.fr/mozilla/bugzilla/pagelongueTPNGfixed.htm

[Viipale+bugzilla (viipale+bugzilla)]

Another site with scrolling problems: http://www.bhmotorsports.com/
With smooth scroll turned on it is really painful to scroll. I tried saving the
page on my computer and then deleted the "background-attachment: fixed" from the
stylesheet. After that no more scrolling issues.

[Sfraser-bugs (sfraser-bugs)]

Another example: <http://www.macrabbit.com/cssedit/>
This site is much slower to scroll in Camino than in Safari.

[Markushuebner (markushuebner)]

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

[Felix Miata (mrmazda)]

I tried to open URL in comment 62 in OS/2 trunk from last week. I saved it to
disk with wget to check the size - about 550K - after what seemed like an
eternity of 100% CPU load, giving up and closing the tab long before seeing the
bottom of the page. In Linux of like build, it took over five minutes to get to
the bottom of the page after hitting the end key. After 10 minutes I checked
top, and found mozilla-bin CPU load continuing around 96%. Switching to CZ took
over a minute. Switching back to browser took closer to 2 minutes. After 20
minutes, still 96% CPU load, so I X'd the tab, and mozilla-bin fell below 0.1%.
Both systems are K6/2-5x0 with ET6100 PCI video.

[André (andred-ubuntu-deactivatedaccount-deactivatedaccount)]

I guess this bug really doesn't need more test cases, but I just ran into this
side which is extremely slow, so I thought I would point it out. It's much
slower than all other test cases in this bug (perhaps on par with the one in
comment 59)

http://weblogs.mozillazine.org/djst/

[Markushuebner (markushuebner)]

dear bug reports - please try again with a recent build. To me it seems that
nearly all testcases are working fine. So it would be good to be able to
concentrate on the remaining ones.

[Adam-gimp (adam-gimp)]

I've just retested every URL in this bug on Linux/x86/GTKfe on a 750MHz Athlon
with GeForce2 on a June 24th Firebird build and all of the URLs that demonstrate
fixed-background scrolling (rather than a 404 or something quite different)
still perform somewhere between 'quite' and 'very' badly.

[Markushuebner (markushuebner)]

Okay - do you have a win32 system also handy for testing/comparing?

[Adam-gimp (adam-gimp)]

I was about to say 'no' but then I remembered that I do still have a win98
partition kicking around on this disk somewhere... I'll see if I can download
the same MozFB build for mswindows.

[Adam-gimp (adam-gimp)]

(This'll take a while though; can't reboot until I've built this big fat
Subversion repository...)

[Moz2 (moz2)]

I've been trying to get my head around this myself...

OS X g4/400mhz powerbook
Camion 2003062704
Mozilla 2003062708-trunk (native scrollbars & not)

it seems that most of the testcases here that have only a fixed background have
no noticable slowdown. This includes:
the attached testcase
http://www.meyerweb.com/eric/css/edge/complexspiral/demo.html
http://www.esn-leiden.nl/
http://ln.hixie.ch/?count=1000000

However this page still is pretty bad... but i couldn't tell wht was fixed:
http://anomaly.hrunting.org/old.html

This is the only case I noticed where what looks to be a fixed background caused
slownes (could also be the opacity+fixed bg causing the slowdown and not a
simple case of a fixed bg):
http://weblogs.mozillazine.org/djst/

HOWEVER, any cases of position:fixed /content/, such as that seen on:
http://www.macrabbit.com/cssedit/ (mentioned in comment 72)
http://www.w3.org/Style/ (mentioned in comment 22)

...still suffer extremely delayed scrolling and it seems to take 5-10 secs to
scroll the w3c page.

[Felix Miata (mrmazda)]

Using 20030629 vacpp 1.4 branch for OS/2, I found most of the URL's anywhere
from good to slightly glitchy on K6/2-550. The following were moderately glitchy
or worse: comment 54, comment 59, comment 71, comment 72, comment 74

Because of comment 73 experience I didn't even try comment 62 again.

The first URL in comment 22 is nearly hopeless. CPU pegs for a minute or so
after clicking once in the scroll area, and repaint scrolled is horribly
delayed. Multiple clicks made system unresponsive until given enough time for
CPU to drop below 100%. Page is useless except under the most extreme duress.

[Hrunting (hrunting)]

http://anomaly.hrunting.org/old.html

I know what's fixed because I wrote the page. If you look at it in IE, you'll
see how it's supposed to be rendered properly (apparently, newer versions of
Mozilla/Firebird don't render it the same [maybe correct, maybe not] way).

At the top of life4_dom.css, @imported-ed stylesheet is this:

HTML {
  background: #fff url(/imgs/museum.jpg) no-repeat bottom right;
  background-attachment: fixed;
  color: #000;
  margin: 0px;
  padding: 0px;
  width: auto;
}

Unfortunately, it looks like the 'background-color: transparent;' declaration
in the BODY style is being ignored (or converted to white). In any case,
that's what fixed, and yes, it's still unbearably slow (and a CPU hog) in
Windows XP, Firebird 0.6.

[Felix Miata (mrmazda)]

Comment 81 was incomplete. Scrolling behavior on comment 59 was quite glitchy,
but there's another problem on that page. The whole time there my CPU stays
pegged. It drops when I switch tabs, but goes right back up when I return.

My W98 machine has the same K6/2-550 and is every bit as glitchy on comment 59
using 1.4rc3.

[Felix Miata (mrmazda)]

Comment 59 URL apparently loads the CPU so heavily it disconnects Chatzilla,
which won't auto reconnect until I wrest focus from that tab.

[Junk-jiv (junk-jiv)]

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
machines.

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?

[FredBezies (fredbezies-deactivatedaccount)]

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

[Felix Miata (mrmazda)]

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

[Peterhewitt (peterhewitt)]

I seem to experience this problem when using a PNG with alpha transparency. When
I have a normal PNG as my background image it scrolls fast but when there is a
translucent one it scrolls slowly. If the translucent one is set as the main
background and not just for certain parts of the page then it gets even worse.

[Junk-jiv (junk-jiv)]

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
Firebird/0.6.1+
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.

[Junk-jiv (junk-jiv)]

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.

[Junk-jiv (junk-jiv)]

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.

[Junk-jiv (junk-jiv)]

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?

[Holyspirit (holyspirit)]

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...

[Greg Campbell (glc-bugs)]

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)

[Dylan (dylang)]

Here's my end-user experience:

With every Mozilla I've ever run (between when I started using Mozilla 100% of
the time in late 2000 and the 2003101405 nightly I'm currently using), having
any page with background-attachement: fixed; regardless of image type, size, or
other options (JPG, PNG, GIF, etc), the cpu usage will peg at 100% with
Mozilla-Bin (or Mozilla.exe on Windows) eating it up. On my Athlon XP 1700+ I
use for work, there is a noticable delay in scrolling if the page has a fixed
image (image loaded or not).

This is under Linux/X11 under various video cards and drivers, and under Windows
with various cards and drivers.

It's all a matter of latency: on a text page, using the scroll wheel, the latecy
of updates is such that even if I spin the moushe wheel a whole lot, the moment
I stop, the page stops moving. However, with background attachement fixed
images, I can easily enter scroll commands faster than they can be processed,
leading to me watching the browser desperately scroll around long after I've
stopped touching the mouse.

In summary -- :-/

[Markushuebner (markushuebner)]

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?

[Bugzilla-spray (bugzilla-spray)]

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

[Fondacio (fondacio)]

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:
http://weblogs.mozillazine.org/djst/
That page might still serve as a useful testcase.

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

[Bugzilla2005 (bugzilla2005)]

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

[Felix Miata (mrmazda)]

Here's a current Moz-focused page that does this. Totally pegs CPU. I have to X
Moz or the tab the page is in to get the system useful again. 2003120507.
http://texturizer.net/thunderbird/features.html

[Adam-gimp (adam-gimp)]

Hmm, I don't see a fixed background or unusual CPU usage for that page.

[Felix Miata (mrmazda)]

I right click the link in comment 89, then select the tab. 30 seconds elapse
before the tab content even begins to paint, and CPU pegs for 82 seconds. Then I
click the lower scrollbar space, and CPU pegs for 43 seconds.

Hmmm, I just assumed from the presence of background images (several -
http://texturizer.net/mozilla.org/css/colors.css) that they were fixed, and
therefore this bug. Guess not. Wonder which bug I'm seeing?

2003120708 OS/2 on K6/2-550.

[Adam-gimp (adam-gimp)]

I don't know what bug you're seeing, but I'm pretty sure it's not this one. It
sounds like it might be an OS/2-specific rendering problem, since I'm running on
one of the platforms worst-affected by fixed-background's performance and I
don't see a trace of a problem. Furthermore the page linked to from comment 89
has clearly been designed optimally for mozilla-base browser users and thus
would have recieved prior testing on the 'tier one' platforms and unix/mac/win32
users would have kicked up a fuss if there were a problem. So it's very likely
either OS/2 specific or your-system specific. I advise you to file a specific
bug report for it.

[Bugzilla-spray (bugzilla-spray)]

Went trough 90% of the dupes and links on this bug and all of them, expect
http://www.dutchbint.org/ are very very smooth!

[Flo (flo51100)]

http://www.lesproviders.com is very slow here. Firebird 0.7, Windows XP SP1,
PIII 1gh 256ram geforce2.

[Bugzilla-spray (bugzilla-spray)]

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.

[Gandalf-aviary (gandalf-aviary)]

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

[Deleeuw (deleeuw)]

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

[Marcos-br (marcos-br)]

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

Actually, it does. Open
http://www.lesproviders.com/themes/L12_lesproviders/style.css and and you'll see:

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

And to make things worst, it's a <a
href=http://bugzilla.mozilla.org/show_bug.cgi?id=90198>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?

[Marcos-br (marcos-br)]

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

Sorry!

[Miahzmiahz+bmo (miahzmiahz+bmo)]

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
problems.

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.

[James-nospam-rot3k (james-nospam-rot3k)]

I was designing a page and noticed how horrible scrolling was in Firebird 0.7 on
a pretty new Macinosh Dual G$ with 1.5 GBs RAM. After working on it a while, I
decided to see if any bugs have been filed, and here I am. I downloaded the
latest nightly build of Mozilla – Mozilla/5.0 (Macintosh; U; PPC Mac OS X
Mach-O; en-US; rv:1.7a) Gecko/20040205 – and sure enough, the scrolling is still
unbearable. Safari and Internet Explorer for Macintosh both handle this page
beautifully. Here's the page in question:

http://kongming.net/sgz/biographies/wu/huanggai.html

This bug has been in the database for years now, are there actually plans to fix it?

[James-nospam-rot3k (james-nospam-rot3k)]

Yeah, I missed the spell check on Macintosh. And that's a Dual G4 533mHz.

[Sfraser-bugs (sfraser-bugs)]

On your page, scrolling is dominated by text drawing, because you're using
justified text (which goes through a much slower text rendering path).

[James-nospam-rot3k (james-nospam-rot3k)]

I have never seen justified text cause slowdowns in Firebird or Mozilla, and as
I expected, removing the justification from my document made absolutely no
difference. Even if it did, that would be another bug to report, because
Mozilla would be the only browser which faced scrolling slowdowns when justified
text was included in a page. I’d make a test case without the bells and
whistles to demonstrate this, but the URL included in this document also serves
as a perfect example without justified text or anything else like that.

http://ln.hixie.ch/?count=1000000

That page also scrolls painfully slow. It is specifically fixed width
positioning that causes this problem.

[James-nospam-rot3k (james-nospam-rot3k)]

I wish bugzilla had an edit option to I could be lazy. Guess I'll just have to
start proof reading. Not fixed width positioning, simply fixed positioning.
Such as telling a background image to stay in place despite scrolling, or
keeping an image in a certain location on the visible window despite document
position (such as in the page I linked to above).

[David D Miller (justdave)]

yeah, I'll vouch. Hixie's page (as linked in comment 97) hangs Mozilla solid
the moment you touch the scrollbar (OS X 2004010305). I force-quit it after 3
to 4 minutes of spinning beach-ball.

[Bugzilla-spray (bugzilla-spray)]

All the pages scrolls very smooth on my AMD XP 1900+, Radeon 9700, Windows XP.
Is this only Mac issue now?

[Greg Campbell (glc-bugs)]

> Is this only Mac issue now?
No. Still quite slow on my machine, though my machine is very slow by today's
standards: dual PII-300, 256MB RAM, Radeon 7200. Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.7a) Gecko/20040128 Firebird/0.8.0+

[Adam-gimp (adam-gimp)]

The URL is kinda nasty-jerky (and the one in comment 94 is horrible) on my
athlon-750 with GF-FX, too, Linux/x86.

[Andre-andre-langhorst (andre-andre-langhorst)]

most urls (hixie too) are really fast (2ghz) for me (firefox 0.8, win32), but
this one still is *very* slow http://weblogs.mozillazine.org/djst/

[Bugzilla-spray (bugzilla-spray)]

Can anyone reproduce this with a new build and a page that actually uses
position:fixed?

[Greg Campbell (glc-bugs)]

http://www.w3.org/Style/Examples/007/scrollbars.html - scrolls at about half the
speed of a page without fixed elements.

http://firefox.bric.de/index.php - 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
Firebird/0.8.0+

[Junk-jiv (junk-jiv)]

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
keys:

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

[Jon Henry (jon.henry)]

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

[James-nospam-rot3k (james-nospam-rot3k)]

Okay, I was just at my friend’s place using what I believe was Firebird 0.7
stable on Windows XP. The site
http://kongming.net/sgz/biographies/wu/huanggai.html worked basically
flawlessly. The scrolling was perfectly smooth. Yet the problem persists in
recent nightly builds of Firefox for OSX and badly so on a good dual processor
G4 (I’m unable to use the most recent build because it crashes on launch). If
there is any additional information I can get on this one that would be of use
to anyone, please let me know.

[Rp-moz (rp-moz)]

In reply to #38, yes this bug is still very noticable. If you go to
http://www.tweakers.net and scroll from the bottom up you'll see sluggish
scrolling at the top of the page. It uses many abs. positioned DIV's, some are
hidden some are not so the slow scrolling may be a combination of this bug and
bug 203439 - slow scrolling due to hidden, fixed-position elements, although the
latter probably depends on this one.

[Bogdan-stroe (bogdan-stroe)]

Another very slow site:
http://www.eclipse.org/proposals/eclipse-webtools/index.html

[Kyoung6 (kyoung6)]

Of the last two sites posted, my browser works the opposite than those of the
guys who posted. It seems to be an arbitrary bug. I'm using v 0.8 on a Dell
8200 with Windows XP.

[Laubzega (thorgal-wfmh)]

Over the years that passed since I'd filed this bug I've observed that a lot
depends on how much memory you have available on your graphics card, which in
turn means that slowness is most probably caused by compositing operations (that
are required to prepare pages with fixed background and/or elements) using
pixmaps located in mainboard's RAM rather than gfx-board's RAM. For example, I
had real trouble replicating this bug when using Radeon 9700 with 128MB.

I've alluded to this before (see comment #21): is everything ok with Mozilla's
handling of offscreen pixmaps?

[Ask-swva (ask-swva)]

I have a Radeon 9700 128MB (latest drivers) and my system is Dual Athlon XP
1700+ w/ 1024MB RAM and I still see the problem with the first attachment. It
may also have to do with the size of the window (I run 1600x1200 normally, but
the problem isn't as bad if I shrink the window).

[Olivier Cahagne (wolruf)]

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

[Yupa (yupa)]

Just upgraded to 0.9 and am now experiencing this bug at this site (front page
and any page with the planet background):

http://www.bohemiandrive.com

My user-agent:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.8

My old user-agent, with which I didn't experience the bug:

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

Have never had slowdown in IE 6 with the page.

Did some testing with the same background image on a simple page, and the
slowdown only happens when the background is both fixed and no-repeat:

background-attachment: fixed;
background-repeat: no-repeat;

If the background is just one-or-the-other, the slowdown doesn't happen.

[Felix Miata (mrmazda)]

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

[Yupa (yupa)]

(In reply to comment #111)
> Just upgraded to 0.9 and am now experiencing this bug at this site (front page
> and any page with the planet background):
>
> http://www.bohemiandrive.com

The above site now uses a non-transparent background image, so the slowdown/100%
CPU bug no longer occurs.

[Rajeev-hoojamomma (rajeev-hoojamomma)]

This definitely appears to be a graphics-card-related bug. I used to have an ATi
Rage 128 Pro, and this bug appeared fully. I just upgraded to a ATi Radeon 9600
(256mb, AGP 4x) and this bug does not appear at all (or is at least so reduced
that I can't notice it). Maybe this means that there is some inefficency in the
scrolling, fixed position, or transparency code?

[G01457013 (g01457013)]

Scrolling is slow also on the following webpage:

http://www.vpro.nl/programma/zomergasten/

I think this one is related to the other examples, as it also has a fixed
background.

By the way: I am using an ATi Radeon 8500 LE graphics card, and I do experience
the slow-scrolling phenomenon. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.7) Gecko/20040708 Firefox/0.9.2 (MOOX-AV).

[Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs)]

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

[SteBo (stebo)]

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

[Raikenreiner (raikenreiner)]

(In reply to comment #115)
> Scrolling is slow also on the following webpage:
>
> http://www.vpro.nl/programma/zomergasten/
>
> I think this one is related to the other examples, as it also has a fixed
> background.
>
> By the way: I am using an ATi Radeon 8500 LE graphics card, and I do experience
> the slow-scrolling phenomenon. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
> rv:1.7) Gecko/20040708 Firefox/0.9.2 (MOOX-AV).

url given at the beginning of the bug scrolled slow while it was loading for
about 5 sec then worked fine on scrolling, however #115's url was slow from the
start and stayed slow using a Geforce 2 MX/400 PCI 64 MB sdram with 1.1 ghz p3
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041019 Firefox/1.0

[Astrospy002 (astrospy002)]

Yep I get slow scrolling here as well.
http://www.vpro.nl/programma/zomergasten/

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041019
Firefox/1.0 (MOOX M3)

System Specs:
Windows XP SP1a, GeForce 4 Ti 4200, 256 MBs of RDRAM, P4 2.4 gHz

[Ian Neubert (ian-twacomm)]

I'm seeing this in Linux as well, I'm running Xorg 6.8.0 and dual monitors with
Xinerama.

Mozilla/5.0 (X11; U; Linux x86_64; rv:1.7.3) Gecko/20040929 Firefox/0.10.1

[Benjamin-streeck (benjamin-streeck)]

This is basically one of last major problems of the Gecko engine. Looking at
Opera 7.6 they seem to have fixed all their speed-related problems in Presto.
For me, this makes smooth scrolling not usable, which is quite sad I find.

(FYI: This page is the best (worst) example I've found showing the problem:
http://www.streeck.com/homepage.html )

Occurs in Win2k and WinME: Fx 0.10.1, Fx 1.0rc1, Moz 1.7.3, Moz 1.8a4

[Bugzilla-mcsmurf (bugzilla-mcsmurf)]

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

[Bugzilla-mcsmurf (bugzilla-mcsmurf)]

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

[Matt Sicker (jvz)]

Oh boy, you don't want to see what it looks like when you position:fixed; a
flash or shockwave object; CPU usage goes out the window at over 50% on a P4C
clocked 3.09 GHz, 1 gig RAM, GeForce FX 5900. You'd think that my box could
handle this, but it's definitely a bug.

Demonstration of flash/whatever: http://www.bungie.net
At least they plan on changing the site when Halo 2 comes out, but this is still
an annoying bug.

[Crion (crion)]

Same problem here:
http://www.monti-web.de/

I think the severity of this bug should be pushed up, its really annoying and
seems to be more than two years old now...

[Pcmaniac (pcmaniac)]

this bug was opened 2003-04-09
whats so special about it that cant be fixed in more than a YEAR?

i have a P4 2.8, 512 DDR, ATI Radeon mobility (64 DDR) and scrolling is still
too slow!
btw, this bug isnt only for win2k.. i use xp

[Bugzilla-spray (bugzilla-spray)]

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

[Ryanvm (ryanvm)]

http://www.warp2search.net/ also exhibits this problem. I've experienced the
issue with Windows XP SP1 & SP2 and Windows 98. This is an issue for more than
just Windows 2000.

[Dalangalma (dalangalma)]

www.bungie.net also exhibits the problem.

[Dave Milford (davemilford)]

This isn't just a Win2K bug, it's also evident on Windows XP and Linux. Not
sure about other platforms -- assuming they are also affected.

This is starting to become a very high profile bug, one that has turned off at
least one person I know from Firefox. I got him to switch with 1.0PR, but he's
into Halo 2 (as a huge number of my friends now). With the way Bungie.net is
designed (a very central part to Halo 2's multiplayer), it's painfully slow in
Firefox and fine in IE.

[David-rossde (david-rossde)]

This might be a symptom of bug 124150. See my comment 66 in that bug.

[Felix Miata (mrmazda)]

http://www.w3.org/Style/ isn't quite so bad as
http://www.w3.org/Style/Examples/007/menus.html in current OS/2 trunk. The
latter is still unacceptably slow. http://weblogs.mozillazine.org/djst/is still
really bad. http://texturizer.net/thunderbird/features.html remains as described
in comment 89, clearly the worst of the links included in this comment. None of
the others I tried seem particularly bad any more, including the attached
testcases and http://ln.hixie.ch/?count=1000000

[Olivier Cahagne (wolruf)]

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

[Ozeki (turkmanzone)]

Those who play Halo 2 on Xbox Live usually go check their stats on Bungie.net
(http://www.bungie.net/stats/) and by "Those" I mean this:

Halo 2 - Xbox Live Statistics
(last 24 hrs)
Unique Players: 351,639
Matches Logged: 802,034
Players Online: 71,505

Hopes you guys can fix that soon, because it's getting pretty big now. Sorry
that I can't help. :/

[Martijn-martijn (martijn-martijn)]

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

[Jfftck (jfftck)]

I am using the User Agent Switcher and set my agent string to Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1) and the bungie.net stats page scrolls
much better. I am using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0. But the page is still slow, but now it is
useable now.

[Martijn-martijn (martijn-martijn)]

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

[Mozillafirebird (mozillafirebird)]

seems to be fixed in 2005-01-08-07-trunk

[Peter-vanderwoude (peter-vanderwoude)]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050107
Firefox/1.0+

I tried this attachement
https://bugzilla.mozilla.org/attachment.cgi?id=139911

definitly NOT wfm

[Mozillafirebird (mozillafirebird)]

maybe it doesnt work for u because ur using yesterdays build, and it was only
fixed today. thats why i said it was fixed as of 2005-01-08-07-trunk. ur using
2005-01-07-?-trunk.

[Peter-vanderwoude (peter-vanderwoude)]

(In reply to comment #58)
> maybe it doesnt work for u because ur using yesterdays build, and it was only
> fixed today. thats why i said it was fixed as of 2005-01-08-07-trunk. ur using
> 2005-01-07-?-trunk.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050108
Firefox/1.0+

WFM

All testcases are fast

My stupidity,used the wrong build before

[Peter-vanderwoude (peter-vanderwoude)]

All checkins between 20050107 and 20050108 Win builds

bug 259126 [Firefox]-sites/exceptions list allows invalid hostnames [Win]
bug 187508 [Core]-Follow "full keyboard access" setting in System Preferences
for tabbing navigation [Mac]
bug 250276 [Core]-right-click, cut of BM inside folder inside PT crashes [@
nsMenuPopupFrame::SetCurrentMenuItem ] (aviary) [Lin]
bug 275828 [Toolkit]-#ifdef MOZ_THUNDERBIRD statements in Extensions Manager
hose Sunbird [All]

One of these must have fixed something...

[Greg Campbell (glc-bugs)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050108
Firefox/1.0+

I checked the testcases and they are close, but I still notice a subtle
slowdown. I recently upgraded my motherboard and processor and all the
fixed-element slowdowns got significantly better from the hardware upgrade.

Someone with an older/slower machine should test this since that's where the
slowdown is most noticeable.

[Aklitzing (aklitzing)]

Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.8a6) Gecko/20050108
Firefox/1.0+

I still have slowdown with the testcases. But it is faster then my
Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.8a5) Gecko/20041122

P2 450 Mhz

[Bugzilla-spray (bugzilla-spray)]

www.bungie.net is still slow for me, latest trunk build, Windows XP, Pentium 4,
3,2 ghz, ATI Radeon 9800XT

[Mozillafirebird (mozillafirebird)]

mine scrolls fine

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050109
Firefox/1.0+
Windows XP Home SP2
Pentium 4 2.53 GHz
80 GB HD
512 MB DDR Ram
ATI Radeon 9200 128 MB

[Junk-jiv (junk-jiv)]

About all the recent WFM comments:

1) If you're testing this with a relatively new machine, pull your task manager
up and check CPU usage. You may be surprised how much is going on, even if you
can't see it. See Comment 40.

2) Back when I was really trying to isolate this bug, it seemed like it only
started showing up after a certain something happened--fine up to a point, and
then suddenly slow--but I could never find out what that something was.

For what it's worth, the bungie site is still ridiculously slow for my machine
using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050107
Firefox/1.0+

Should we update the URL to http://www.bungie.net/, since the w3c scrollbar site
doesn't (visibly) show this bug on most people's machines?

[Junk-jiv (junk-jiv)]

Just noticed I was using the build you were complaining about, ColdFusion.
Unfortunately, I still get this even with today's build.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050109
Firefox/1.0+

[Peter-vanderwoude (peter-vanderwoude)]

Created an attachment (id=170761)
testcase with 100 fixed elements

Roughly the same testcase as before, just simpler, but with 100 fixed elements.

( after discussion what causes http://www.bungie.net/ to still be slow )

[Mozillafirebird (mozillafirebird)]

i have a fast computer, and on the regular test cases, it scrolls fine and the
cpu usage is at 2% (which a bunch of other programs running). the one with 100
fixed elements scrolls somewhat slower. barely noticable, and still only 2% cpu
usage. it seems that the new builds only minimize the affect of the fixed elements.

[Uruviel-uruviel (uruviel-uruviel)]

the tescase with 100 fixed elements scrolls notably slower on my pc (P4 1,6Ghz;
512MB DDR-RAM) with 20050110 Firefox/1.0+ . But if we look practicly
http://www.bungie.net/ is a site with over 30 fixed items, you can hardly call
that efficient coding. So you might wonder if the slow behavior of FF is not the
webdesigners fault

[Peter-vanderwoude (peter-vanderwoude)]

Created an attachment (id=170842)
transparent image for next testcase

[Peter-vanderwoude (peter-vanderwoude)]

Created an attachment (id=170843)
Testcase with 100 fixed transparent images

Wanna see slow.... ?

[Miahzmiahz+bmo (miahzmiahz+bmo)]

I see no noticeable difference between 1.0 and 20050110 on my 400MHz pII, 384MB
RAM, 16MB Nvidia TNT running at 1024x768x32.

For me the Bungie site is 2-3x slower than the "100 fixed transparent images"
test with either build, taking about 10 seconds per "scroll."

[BK (knitterb)]

User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

I'm noticing HORRIBLE performance in general with FireFox. I remember this back
in the Mozilla 1.6 days. It turned out to be a memory leak on that issue. When
running Horde (www.horde.org -- a web based mail client) the site refreshes
every 5 mintues. I'm just guessing here, but perhaps the meta refresh, or
javascript refresh, just isn't releasing the memory from the previous page.

After leaving my laptop (2.4 gHz w/ 1G memory) running for 24 hours, refreshing
away at my.yahoo.com and Horde, FireFox will gobble up almost 300M of memory.
Making it perform /really/ badly. On numerous occasions I've even had to just
kill the process.

I'm not sure how to provide debug information on what's being gobbled up, but
I'd happily perform some debug steps/logging for anyone whom needs it.

Cheers!

[Henktiggelaar (henktiggelaar)]

I visited a site today which pretty much brought my Firefox to it's knees
(20050117). I made a <a href="http://www.n3t.nl/mozbug/">minimal tescase</a> and
found something weird.

When I was making the testcase with Dreamweaver MX 2004 I found out the
scrolling speed improved. Closing Dreamweaver made it go slow again. Even after
I restarted my computer this behavior continued (having Dreamweaver open in the
background / minimized improved the scrolling speed of this page in Firefox).
Can anybody who has Dreamweaver MX 2004 confirm this?

[Ger Teunis (g-teunis)]

Testcases are still slow here too.
Perhaps the bug 265610 is getting duped now by the widening of this bug
(transparant images).

[Dgrimm (dgrimm)]

Nominating as 1.1 blocker due to performance issue, and apparently significant
number of users affected based on votes/cc list.

[SteBo (stebo)]

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

[L3ert (l3ert)]

From my testing, I found that it seems to be a combination of image types (png,
gif, bmp, jpg), image sizes (width and/or height not file size) and font size
(px, em, pt, ex or Text Zoom).

Image types and sizes:

* gif: above a certain width and height with or without no-repeat scrolling
becomes very slow.
* png: if the image is repeated too much, scrolling becomes very slow.
* bmp: no problems.
* jpg: no problems.

Font sizes:

With background-attachment: fixed;, with or without an image, if the font size
is too big scrolling becomes very slow.

From my tests, on a fresh install of mozilla 1.8a6 with a new profile, scrolling
becomes very slow with font size above these:

* font-size: 17px;
* font-size: 1em;
* font-size: 13pt;
* font-size: 2.4ex;

My computer:

* AMD 1.4Ghz
* 768MB
* Kyro II
* Windows 2000

My tests can be found here: http://jove.prohosting.com/~l3ert/Fixed/

[Crion (crion)]

Dear bert,

test3 and test5 are really slow here ->
FireFox 1.0 on WinXP SP2
all others where ok.

Thanks for testing!

[L3ert (l3ert)]

test3 and test5 are the only ones slow for me too. But all the others tests can
be made slow too by simply increasing the font size (either via CSS or directly
with View -> Text Zoom). In my case, the font increase needed is minimal (from
100% to 110%).

[Twanno (twanno)]

(In reply to comment #103)
> most urls (hixie too) are really fast (2ghz) for me (firefox 0.8, win32), but
> this one still is *very* slow http://weblogs.mozillazine.org/djst/

While scrolling http://weblogs.mozillazine.org/djst/ works fine for me (cpu
usage up to 80% though), scrolling pages from the archives (e.g.
http://weblogs.mozillazine.org/djst/archives/007482.html) is terribly slow (cpu
usage 100%).
Both pages use the same (fixed) background image, however.

As for berts tests: both test3 and test5 are a bit slower, but increasing the
textzoom (up till 160%) doesn't make the other tests slower

[Matt Sicker (jvz)]

Alright, not only is there a significant rise in CPU usage [still], there is
most likely a memory leak along with it. If I recall correctly, multiple tabs
or subsequent viewings of pages such as bungie.net have an after-effect of
larger memory usage (and commit charge? it doesn't seem to use the memory it
creates, hinting at a leak). I'd recommend somebody make some memory dumps of
Firefox for scrolling on a normal page (like this one) and ones for pages with
massive amounts of overhead-inducing elements (such as bungie.net).

Also, if anyone could test this using a debug version of FF (enable/create the
debugs for any possible pages that include the code that may be inducing this)
and check back with us.

We should also try to find any other programs that improve or lag the
performance while doing so. This may seem like a bit of work to do (it is if
you're not used to debugging things...), but the fact that we haven't found what
is actually causing this bug yet after _almost_2_years_ calls for some major
hacking.

Primary areas to check: anything to do with page drawing, including the XUL bits
and CSS-related bits. Also, check the JavaScript core pages that include the
functions used to simulate position-fixed scrolling and the frameset-related
core bits as these two methods of pseudo position-fixed elements appear to work
in a more orderly and optimized manner.

~Matt

Also, would Mr. McCormick please add an alias to this bug, maybe
"position-fixed"? Thanks.

[Djst-mozilla (djst-mozilla)]

(In reply to comment #128)
> While scrolling http://weblogs.mozillazine.org/djst/ works fine for me (cpu
> usage up to 80% though), scrolling pages from the archives (e.g.
> http://weblogs.mozillazine.org/djst/archives/007482.html) is terribly slow (cpu
> usage 100%).
> Both pages use the same (fixed) background image, however.

Both pages use the same background, but the archives have a alpha transparent
background for the blog entries. I removed it from the main page because I
couldn't stand the poor performance after switching to Linux, but I forgot to
remove it from the other pages.

I found that after switching to the nvidia drivers in Linux, the performance is
improved, but not nearly as good as in Windows.

[Gavin Sharp (gavin-sharp)]

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

[Steve-england (steve-england)]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050313
Firefox/1.0+
win2ksp4,axp2400,nvidia gf4 (v71.84 drivers),1024x768x32@100Hz
(note I use the ad-blocking userContent.css stuff from
http://www.mozilla.org/support/firefox/adblock to get rid of any scrolling
problems because of ads)
Are people on windows 2000/xp still seeing this bug? I've been through all the
urls posted and all the testcases from http://jove.prohosting.com/~l3ert/Fixed/
and it's only tests 5 & 12 are giving me minor slowdown. the other tests run fine.

from a trawl of previously posted comments there's one or two web pages that
still give me a little slowdown
- http://www.bhmotorsports.com/

but the other examples are fine for me now
- http://www.meyerweb.com/eric/css/edge/complexspiral/demo.html
- http://www.w3.org/Style/Examples/007/menus.html
- http://anomaly.hrunting.org/old.html
- http://ln.hixie.ch/?count=1000000
- http://kongming.net/sgz/biographies/wu/huanggai.html

[Sugar-waffle (sugar-waffle)]

(In reply to comment #131)
> Are people on windows 2000/xp still seeing this bug? I've been through all the
> urls posted and all the testcases from http://jove.prohosting.com/~l3ert/Fixed/
> and it's only tests 5 & 12 are giving me minor slowdown. the other tests run fine.

In Windows 2K/XP, it might improve very much by fix of bug284716.
But in it etc. Mac, it is very heavy.

[G01457013 (g01457013)]

(In reply to comment #128)
> While scrolling http://weblogs.mozillazine.org/djst/ works fine for me (cpu
> usage up to 80% though)

Indeed, the main page is okay, but the comment pages (for instance:
http://weblogs.mozillazine.org/mt/comment.cgi?entry_id=7722) are still very slow.

I have done some recent testing, using build Mozilla/5.0 (Windows; U; Windows NT
5.0; en-US; rv:1.8b) Gecko/20050218 Firefox/1.0+ (MOOX M2). I am using an Ati
Radeon 8600LE with Catalyst 4.6 drivers (certainly not the latest, but changing
drivers has never seemed to make a difference for this particular problem).

Some pages that were slow before seem to work fine now:

http://ln.hixie.ch/?count=1000000
http://www.w3.org/Style/
http://www.w3.org/Style/Examples/007/menus.html
http://www.meyerweb.com/eric/css/edge/complexspiral/demo.html
http://kongming.net/sgz/biographies/wu/huanggai.html

However, a few pages still suffer from slow scrolling:

http://www.vpro.nl/programma/zomergasten/ (very noticable)
http://www.eclipse.org/proposals/eclipse-webtools/index.html (slight delay)
http://weblogs.mozillazine.org/djst/archives/007482.html (terribly slow)

The first also appears to be slow in IE, the others do not.

(I haven't experienced any slowdowns for the other example pages mentioned
above, but I suspect that a lot of them have been altered since they were listed
as an example in this bug-thread.)

The testcases at http://jove.prohosting.com/~l3ert/Fixed/ are okay, except for
tests 3 and 5. Increasing the font size doesn't seem to matter here.

[Gavin Sharp (gavin-sharp)]

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

[Bugs-caleb (bugs-caleb)]

What about this page:
http://www.euronet.nl/users/frankvw/rants/microsoft/IhateMS_2.html

The scrolling is dead slow, in fact, it's unbearable.

[Ivan Icin (ivanii)]

(In reply to comment #78)
> What about this page:
> http://www.euronet.nl/users/frankvw/rants/microsoft/IhateMS_2.html
>
> The scrolling is dead slow, in fact, it's unbearable.

It is very smooth for me. Maybe cause I'm using more up-to-date version:
Gecko/20050326 Firefox/1.0+

[Ask-swva (ask-swva)]

The problem with declaring that a testcase works or not is that this effect is
resolution-dependent. The most recently mentioned testcase scrolls horribly for
me at 1600x1200, which I use normally, but if I resize the window to say,
800x600, it works fine. It's not a version issue since I'm using Gecko/20050404
Firefox/1.0+

[Ozeki (turkmanzone)]

(In reply to comment #78)
> What about this page:
> http://www.euronet.nl/users/frankvw/rants/microsoft/IhateMS_2.html
>
> The scrolling is dead slow, in fact, it's unbearable.

It works pretty fine with my version of FF (Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2).

I think the worse ever case is http://www.bungie.net and by far.

[Tim Kosse (tim-kosse)]

I have observed something interesting:
It only seems to happen for me if I have enabled ClearType font antialiasing.
With normal or disabled font antialiasing, scrolling speed is bad to normal,
same speed as with Internet Explorer.

Tested with FF 20050410 nightly trunk under Windows XP SP2.

[Bugs-caleb (bugs-caleb)]

(In reply to comment #79)
> (In reply to comment #78)
> > What about this page:
> > http://www.euronet.nl/users/frankvw/rants/microsoft/IhateMS_2.html
> >
> > The scrolling is dead slow, in fact, it's unbearable.
>
> It is very smooth for me. Maybe cause I'm using more up-to-date version:
> Gecko/20050326 Firefox/1.0+

In fact, you are using an outdated version.
I'm using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050410
Firefox/1.0+

And that www.bungie.net site scrolls just as slow as the link I posted.

[Ozeki (turkmanzone)]

(In reply to comment #83)
> (In reply to comment #79)
> > (In reply to comment #78)
> > > What about this page:
> > > http://www.euronet.nl/users/frankvw/rants/microsoft/IhateMS_2.html
> > >
> > > The scrolling is dead slow, in fact, it's unbearable.
> >
> > It is very smooth for me. Maybe cause I'm using more up-to-date version:
> > Gecko/20050326 Firefox/1.0+
>
> In fact, you are using an outdated version.
> I'm using:
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050410
> Firefox/1.0+
>
> And that www.bungie.net site scrolls just as slow as the link I posted.

I confirm. I just installed the latest trunk release from Burning Edge (
Gecko/20050405 Firefox/1.0+) and there is an HUGE improvement in the scrolling
of bungie.net.

But FF 1.0.2 was very slow. There's still a little lag in the scrolling of
pages, but it's definitively smoother now. :)

[Ericeberg (ericeberg)]

(In reply to comment #84)
> I confirm. I just installed the latest trunk release from Burning Edge (
> Gecko/20050405 Firefox/1.0+) and there is an HUGE improvement in the scrolling
> of bungie.net.
>
> But FF 1.0.2 was very slow. There's still a little lag in the scrolling of
> pages, but it's definitively smoother now. :)

I can vouch for this as well. The scrolling on the pages referenced (bungie.net,
euronet.nl, testcases) is very smooth now, and better than comparable to IE6.
Using Gecko/20050413 Firefox/1.0+

[Junk-jiv (junk-jiv)]

Who knows why, but the last two comments are absolutely right!
Current trunk builds are displaying these much, much better than previous ones.
Bungie and the euronet.nl site both still consume 100% CPU on my machine, but
scroll (relatively) smoothly.

The original test cases all scroll beautifully, with negligible (~2%) CPU use. I
would probably have to consider this fixed :)

Oddly enough, though... I did some testing using variations of the 100-div test
case (11 divs, 22, 33, etc) and found that CPU use stays that low until about 25
fixed divs are present. After that, I get odd spikes, until at 30 I have pretty
much solid 50% or above usage. From there it rapidly hits 100%, but (as seen in
the bungie site) even with huge numbers of such elements, the 100% usage doesn't
translate to poor performance. Yay!

I wonder why CPU use is behaving so oddly... I'd have expected something more
linear. It feels like it's having to "clean up" after drawing a certain number
of frames, and as you increase the amount of drawing it has to keep track of,
that cleanup becomes less erratic and more constant. Then again, I have no idea
what I'm talking about. =P

In other news, I think the change comes from bug 205893, and after reading
through that one and bug 284978, I think I have an idea of what's going on in
the above two paragraphs, too. That's all I have time for tonight though. I
guess I would consider this resolved.

[Ericeberg (ericeberg)]

On the other side of the coin, the latest Mac builds of Firefox and Camino (the
20050413 builds) are still horrendously slow on these sites (this is a 700MHz G4
iMac with 10.3.8), so I wouldn't resolve this bug just yet. This could be
related to issues with Quickdraw; nevertheless, I think this bug deserves more
investigation. Even sites like Gamespot (http://www.gamespot.com/) lag a bit due
to all the multimedia (graphics, flash, etc.).

[L3ert (l3ert)]

I installed Mozilla 1.7.7 and scrolling is greatly improved (still not as smooth
as on IE or Opera).

After installing 1.7.7 I had to install an extension uninstaller
[http://mozmonkey.com/extuninstaller/] in order to remove the undoclosetab
extension [http://extensionroom.mozdev.org/more-info/undoclosetab] because it
made tab impossible to close (either via the X or by midle-cliking them).

Unfortunately, the extension uninstaller API didn’t install because of a script
error so I had to uninstall undoclosetab manually
[http://kb.mozillazine.org/Firefox_:_FAQs_:_Uninstall_Extensions].

After having uninstalled undoclosetab I reinstalled it.

After that I tried several test cases concerning the slow scroll bug and noticed
the improvement.

I don't know if it was 1.7.7 that caused the improvement or if it was
undoclosetab that somehow caused the problem in previous versions.

Still the bug (if it is a bug anyway) is not fully resolved for me but the
improvement is notable.

[L3ert (l3ert)]

I just realized that what I wrote about undoclosetab and extension uninstaller
doesn’t make much sense since I previously tested the bug on a clean install of
mozilla 1.8a6 [https://bugzilla.mozilla.org/show_bug.cgi?id=90198#c125].

So it's probably 1.7.7 (also tried 1.8b and it gives similar results to 1.7.7).

[Brackbillbruce (brackbillbruce)]

Here is another page that is VERY slow on scroll ( more with keyboard than mouse ):
http://www.csszengarden.com/?cssfile=http://www.pro-ymd.co.jp/zen/sample.css

I'm using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323
Firefox/1.0.2 Fedora/1.0.2-1.3.1 with evil binary Nvidia GeForce2 64 mb, AMD 1.4Ghz

[Steve-england (steve-england)]

Is position:fixed is the same as background-attachment:fixed?

I only ask because www.warp2search.net is a scrolling nightmare (make sure you
are not blocking ads if you want to observe the poor scrolling). But on removing
background-attachment : fixed;
from body { ) definition in style.css - the page goes from scrolling nightmare
to fast & responsive.

[Junk-jiv (junk-jiv)]

That would be bug 90198. Since they've shown up (and not shown up!)
independently of each other, I think they're two entirely different problems.

[Jfftck (jfftck)]

Created an attachment (id=192468)
Testcase that shows how the fixed elements should act

I think this should stay open until fixed elements act the same as elements
objects with a scrolling element under it. This testcase will also work in IE
and shows that normal scrolling can happen with elements that don't move.

[Jfftck (jfftck)]

It is like the fixed elements are on a different paint event compaired to all
other elements. I don't know anything else that would cause fixed elements to
lag behind all other elements. I also would not write-off this bug just because
faster computers don't show this bug being that bad. Right now Microsoft is
writing-off all OSs under XP, we should not do the same.

[Roc-ocallahan (roc-ocallahan)]

We understand exactly what the issues are here. They're just not going to be
fixed for 1.8. 1.9 should be a lot better.

[Dtownsend (dtownsend)]

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

[Adam Guthrie (ispiked)]

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

[Jo-hermans (jo-hermans)]

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

[danone (mhsurfer-deactivatedaccount)]

Unfortunately I have to confirm this rather old bug as I experienced same problem using my current:

Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.1) Gecko/20060226 Debian/1.5.dfsg+1.5.0.1-3 Firefox/1.5.0.1

and also crosschecking with newest (using new profile!):

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060308 Firefox/1.6a1

Testcase on http://jove.prohosting.com/~l3ert/Fixed/test5.html scrolls VERY slow with both. Using Opera or Konqueror it nearly scrolls at the speed of light :-(

[Mozilla-kaioa (mozilla-kaioa)]

(In reply to comment #125)
[...]
> * gif: above a certain width and height with or without no-repeat scrolling
> becomes very slow.
> * png: if the image is repeated too much, scrolling becomes very slow.
> * bmp: no problems.
> * jpg: no problems.

I used some 1px thin repeat-x png before and it wasnt fun. A width of 4000px and no repeat was faster, but still not smooth. And with a (1px thin) repeat-x jpg its perfect.

The image format really does make a difference. Completely weird if you ask me.

[Sfraser-bugs (sfraser-bugs)]

(In reply to comment #142)

> The image format really does make a difference. Completely weird if you ask me.

Is the real issue images with transparency vs. those without?

[Vseerror (vseerror)]

mhsurfer comment #141:
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060308 Firefox/1.6a1
>
> Testcase on http://jove.prohosting.com/~l3ert/Fixed/test5.html scrolls VERY
> slow with both. Using Opera or Konqueror it nearly scrolls at the speed of
> light :-(

WFM
http://jove.prohosting.com/~l3ert/Fixed/test3.html
http://jove.prohosting.com/~l3ert/Fixed/test5.html

of the 8-10 other links mentioned in the bug that I tested, all WFM.
modest machine 3.2G P4
trunk seamonkey and firefox

is there any link that still gives someone trouble with trunk builds?

[Jure Repinc (jlp)]

I checked all the links from this bug report (not from duplicates) in Firefox nightly 20060607 for Linux and these two pages still scroll slowly:
http://kongming.net/sgz/biographies/wu/huanggai.html
http://www.csszengarden.com/?cssfile=http://www.pro-ymd.co.jp/zen/sample.css
They both work just fine in Konqueror 3.5.3.

[Vseerror (vseerror)]

(In reply to comment #145)
> I checked all the links from this bug report (not from duplicates) in Firefox
> nightly 20060607 for Linux and these two pages still scroll slowly:
> http://kongming.net/sgz/biographies/wu/huanggai.html
> http://www.csszengarden.com/?cssfile=http://www.pro-ymd.co.jp/zen/sample.css

News from the linux world :)

If all windows stuff here is fixed, perhaps this bug should be changed to meta morphed to linux or the 3 blocking bugs (244506 244862 271952) moved to meta bug 100951 or 201307. otherwise, people may keep commenting here about windows, even though it no longer applies to windows.

If nothing else, you might mentioned these URLS in one of the blocking bugs (bug 244862?) or create a new bug so they don't get lost in this massive bug.

[Darin-moz (darin-moz)]

Not going to block 1.8.1 for this bug.

[Adam Guthrie (ispiked)]

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

[Mailbox-partysaarfari (mailbox-partysaarfari)]

http://stegmann-w.de/ <- scrolling on that page is very slow. Anybody an idea why this happens?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060625 BonEcho/2.0a3 ID:2006062503

It's much faster in Opera 9

Looks like it's caused by the fixed background ?!

[Wjrogers-terpalum (wjrogers-terpalum)]

(In reply to comment #149)
> http://stegmann-w.de/ <- scrolling on that page is very slow.

This page is noticeably slow to scroll for me, also. I'm not sure why people are saying this no longer affects Windows?

P4 2.8 GHz w/ Matrox P650 graphics card. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060625 BonEcho/2.0a3 ID:2006062503

[Stadli (stadli)]

The following example is even worse: http://www.debianhowto.de/doku.php/de:howtos:sarge:exim4_vexim2_courier_mailman

Oh and btw: is there any bug about that flickering, when I'm scrolling?

[Jacekchmiel (jacekchmiel)]

Disabling background image definitely solves the problem (adblocked image and scrolling is smooth).

[Adam Guthrie (ispiked)]

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

[Mailbox-partysaarfari (mailbox-partysaarfari)]

Another page for testing, I get up to 100% cpu on that page:

http://www.gj-igb.de/

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060813 BonEcho/2.0b1 ID:2006081305

[Christoph Roeder (brightdroid)]

Another really good example is http://www.fppdesign.com.au/

I get this Bug in FF 2.0.0.3 and 3.0a3 !

[Samcleaver (samcleaver)]

http://www.beaver6813.com/temp/design/ - The DIV background image is fixed... lags as you scroll down :( Only affects PC Firefox as far as i can tell :/

[Imipak-gmail (imipak-gmail)]

Re: Sam <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=90198#c156">(comment #156)</a> your testcase at http://www.beaver6813.com/temp/design/ worked fine for me (Firefox 2.0.0.3 on Linux) - that is the central column scrolled smoothly and as fast as you'd expect -- until I started randomly clicking bits of the furniture. Suddenly the scrolling of the test-test-test central column became incredibly slow and jerky. I closed the tab, reopened it, still slow and jerky. However! After restarting Firefox altogether, the testcase document scrolls perfectly once again... until I selected part of the 'test-test' text - scrolling immediately reverted to the very slow jerky behaviour.

[Samcleaver (samcleaver)]

Well i've found a work around.. but its certainly not ideal, for the DIV with the fixed background you MUST give it a height for it to not be jerky, trust me, i tried for hours with no success:

height:auto; = jerkiness

height:800px; for example gives no jerkiness

So it basically means if you want to have a DIV with a fixed background image that div must have a height.. or else...

Because of this on places like my blog where i know roughly what the height will be i've used:

height:3500px !important;
height:100%;

Firefox doesn't support 100% and auto doesn't work right so its my only option :(

(Of course correct me if im wrong, i'd always loved to know if theres a better workaround)

[Samcleaver (samcleaver)]

Just for comparison, the previous testcase posted is here:
http://www.beaver6813.com/temp/design/

Testcase with the background NOT jerky:
http://www.beaver6813.com/temp/design2/content.php

[Bugzilla-dogtoe (bugzilla-dogtoe)]

There's an ongoing discussion in the Gentoo Forums about this, titled "why does firefox suck on gentoo.". This issue is happening in Linux as well. Every Windows machine I've encountered does not have this problem. However, there are some Linux machines that simply do not, for whatever reason:

http://forums.gentoo.org/viewtopic-t-536596-highlight-firefox+suck.html

The page in question is a wordpress theme test site, which also has a static background + lots of alpha tranparency:

http://themes.wordpress.net/testrun/?wptheme=701

Things to rule out:
* Pango (makes no difference turning it on/off)
* "Smooth" Scrolling (makes no difference)
* Building from source as opposed to binary
* Also happens with Firefox 3.0 alpha builds

[Marcia-mozilla (marcia-mozilla)]

Seen using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.4) Gecko/2007050903 Firefox/2.0.0.4. I have seen this before during testing on Vista as well.

1. Navigate to amazon.com front page
2. Scroll up and down and pay particular attention to the alignment of the text on the right hand side of the page.

As I scroll up and down, the text loses it alignment. When the scrolling stops, everything realigns fine.

[Gavin Sharp (gavin-sharp)]

I can't reproduce this with a branch build on Windows. Does this happen on the trunk?

[Ilja Sekler (ilja-sekler-)]

 (In reply to comment #160)

> The page in question is a wordpress theme test site, which also has a static
> background + lots of alpha tranparency:
>
> http://themes.wordpress.net/testrun/?wptheme=701

WFM, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/20070528 Minefield/3.0a5pre. The bug seems to be fixed due to the checkin in bug 343430.

[Ilja Sekler (ilja-sekler-)]

I deeply apologize for the spam and the last pointless speculation. The wordpress page in comment #160 scrolls also in older builds flawlessly, thus no relation to bug 343430.

[Marcia-mozilla (marcia-mozilla)]

I can't recall if I tried it on the trunk, but I will. It is a funny bug in that it is difficult to reproduce, but Gerv was actually standing over my shoulder the least time I reproduced it on Vista.

(In reply to comment #1)
> I can't reproduce this with a branch build on Windows. Does this happen on the
> trunk?
>

[Milan-burda (milan-burda)]

I am experiencing this problem, as seen on this screenshot:
http://img.photobucket.com/albums/v647/mu-lan/scrolling.png

It happens both in Firefox 2.0.4 and in the lastest trunk build of Firefox 3.0

It is very obvious on this page:
http://trainofthoughts.org/blog/2007/06/24/openpkg-apache2/

System: Windows XP SP2, Athlon XP 2600+, 1.5 GB RAM, ATI Radeon 9600 XT

[Martijn-martijn (martijn-martijn)]

Milan, I don't think this is the same bug. Actually, I think you're basically experiencing bug 201307.

[Milan-burda (milan-burda)]

Hi, I've been redirected from
https://bugzilla.mozilla.org/show_bug.cgi?id=380181

to this bug regarding a problem with text scrolling on a page with fixed background, where part of the text on the right side is aligned incorrectly in the vertical direction while scrolling and after stopping the scrolling, it gets back to the correct position as seen on the screenshot:
https://bugzilla.mozilla.org/show_bug.cgi?id=380181

this can be observed in both Firefox 2.0.4 and in the latest trunk build
on this page for e.g.:
http://trainofthoughts.org/blog/2007/06/24/openpkg-apache2/

System: Windows XP SP2, Athlon XP 2600+, 1.5 GB RAM, ATI Radeon 9600 XT

[Milan-burda (milan-burda)]

(In reply to comment #4)
> Milan, I don't think this is the same bug. Actually, I think you're basically
> experiencing bug 201307.
>

I'm sorry. I posted it into bug bug 201307 now.

[Mak77 (mak77)]

WFM
Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

[Pascal de Bruijn (pmjdebruijn)]

When visiting this site with Firefox (or Epiphany), scrolling slows down to a crawl:

http://nitens.org/taraborelli/latex

I'd like that to be sped up in the future.

[Pascal de Bruijn (pmjdebruijn)]

By the way,

I've asked a friend to test that very site in Windows using Microsoft Internet Explorer and Opera, and they both don't seem to slow down.

So this issue is very Firefox/Gecko specific.

[John Vivirito (gnomefreak)]

Can you please tell us what version of firefox what version of ubuntu you are using same with epiphany. What extensions, plugins, themes do you have installed? Please see How to report bugs effectively, http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Please provide us with a step by step set of instrctions on how to reproduce this

[John Vivirito (gnomefreak)]

Is that the only link you see this issue with?

[Pascal de Bruijn (pmjdebruijn)]

Uh yes,

I'm using Ubuntu Feisty with Epiphany 2.18.1 and Firefox: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20061201 Firefox/2.0.0.4 (Ubuntu-feisty)

There is nothing else to do, just open the link.

[Pascal de Bruijn (pmjdebruijn)]

I do _not_ have this issue, with any other webpage.

[Márcio Vinícius (marvinmep)]

I believe this bug only happens in Linux (or at least is worst in Linux). I have a dual boot Pc and pages scrolls fine in Windows, but in Linux the same pages scrolls very slowly.

And there is one more thing, the same problem happens when the page has div with (semi-)transparent PNG in backgroung.

[Márcio Vinícius (marvinmep)]

(In reply to comment #163)
> I believe this bug only happens in Linux (or at least is worst in Linux). I
> have a dual boot Pc and pages scrolls fine in Windows, but in Linux the same
> pages scrolls very slowly.

This is reported at https://bugzilla.mozilla.org/show_bug.cgi?id=69020

[Paul van Genderen (paulvg)]

I beg to differ. This bug has been around for years and happens on any page with fixed positioning where the fixed content overlaps static content (and/or vice versa). With the firebug extension*, remove the word 'fixed' from the background rule and scrolling becomes smooth again.

A quick search reveals these 2 bugzilla entries:

https://bugzilla.mozilla.org/show_bug.cgi?id=90198
https://bugzilla.mozilla.org/show_bug.cgi?id=201307

* http://www.getfirebug.com/

[Jsfisher92 (jsfisher92)]

I have this problem in Ubuntu 6.10 using Firefox 2.0.0.5. I first noticed it on the engadget.com web site. I'm dual booting Ubuntu and XP on a ThinkPad T60 and have no problems with Firefox in XP. However, I recently tried Swiftweasel, Epiphany, and Opera, in Ubuntu, to see if that solved the problem and it did not. Perhaps that indicates that the problem goes beyond Firefox itself?

[Anonym25712 (anonym25712)]

Just for the record, I'm also using a ThinkPad T60 but with an Ubuntu 7.0.4 and FF 2.0.0.6. I have no problem at all with the engadget.com web site.

[Pascal de Bruijn (pmjdebruijn)]

Well that option is probably used by very few webpages.

Other browsers seem not to be affected.

And I'm not using Firefox, but Epiphany, so firebug is not an option.

[Márcio Vinícius (marvinmep)]

I didn't try Epiphany. In Opera everything seems right to me. Swiftweasel has the same problem (which is expected, as it is an optimized Firefox). I still believe it is a Firefox's bug. And people reported the same problem with other distributions, which indicates that it is not only a Ubuntu's problem.

The problem is clearly in the relation between Firefox and Linux.

[Jsfisher92 (jsfisher92)]

But then what explains that I do have the same problem with Opera? Presumably it makes sense that the problem also exists with Epiphany, because it's based on the Gecko engine (right?). I don't know how all this stuff works, I just know what's happening on my system.

I did the update to Ubuntu's version of 2.0.0.6 today and it did not solve the problem for me.

[Jsfisher92 (jsfisher92)]

I had an interesting experience upgrading to Feisty and both not having the slow scrolling problem and being able to reproduce it.

First of all, I tried upgrading to Feisty when it first came out and keeping my home parition (but otherwise a clean install), after that I still had the slow scrolling problem.

This time I upgraded to Feisty, with a totally clean install and reformatted home partition. Right away, even without the fglrx driver, the slow scrolling problem went away. Although in this configuration, there was a slight lag with scrolling still continuing for a second after I stopped (but it was very usable). Then I installed the Ubuntu version of fglrx 8.34.8 and also did not have the slow scrolling problem and no lag, although over certain images it will just barely hesitate for a second (almost not noticeable).

However, as soon as I installed Adobe Flash the slow scrolling problem came back. I installed Flash when I went to a site in Firefox that needed it and Firefox prompted me that I needed the plugin. I let Firefox do the install.

So I used my partition images I had made and reverted to my clean install of Feisty and my home paritition. This time I installed Flash first (also through Firefox), before installing fglrx. Then I installed fglrx and do not have the slow scrolling problem. So far (a couple days now) this has remained true.

[marenz (dermarenz)]

Another example of extremely slow scrolling with linux/firefox-2.0.0.6

http://derstandard.at/?url=/?ressort=Linuxx
or one of the linked newsitems
http://derstandard.at/?url=/?id=3014390

scrolling makes firefox/xorg-X11 eat Dualcores :-(

does not happen with windowsXP/firefox-2.0.0.6

[calmar (mac-calmar)]

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007101704 Minefield/3.0a9pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007101704 Minefield/3.0a9pre

Simple scrolling takes very long and 100% CPU

Reproducible: Always

Steps to Reproduce:
1. try to scroll on the example page mentioned
2.
3.
Actual Results:
takes 100% cpu and is very slow (therefore)

Expected Results:
(normal) fast scrolling without 100% CPU usage just for that

[Scott Tringali (tringali)]

For those of you who don't see this:

The slowness is most noticeable when scrolling by page or more: use PageUp/PageDown, Ctrl-Home, Ctrl-End, or click in the scroll bar gutter. Scrolling by keyboard arrow, arrow button, or mouse wheel, doesn't show the problem.

Note I have smooth-scroll turned off. When it's on, it's still slow, but you can see it repaint a few times so feels a little faster.

I see this regularly on Windows Firefox 1.5, Linux Seamonkey 1.1.3, Linux Firefox 1.5 and 2.0.0.4.

[Steffen Wilberg (steffen-wilberg)]

> I see this regularly on Windows Firefox 1.5, Linux Seamonkey 1.1.3, Linux
> Firefox 1.5 and 2.0.0.4.
All of these have known security bugs, and Firefox 1.5 doesn't get security updates anymore. Please update to Firefox 2.0.0.8 and Seamonkey 1.1.5.
And these versions only receive security updates.
If you want to find out what's going on in active development, download a trunk nightly: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Or wait for the Firefox 3 Beta, which should be out in a couple of weeks.

[Kevin Brosnan (kbrosnan)]

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

[Nicolò Chieffo (yelo3)]

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

[Nicolò Chieffo (yelo3)]

I run firefox 2.0.0.8 in ubuntu gutsy. I have both radeon and nvidia cards, and I tried opensource and proprietary drivers. This problem is very annoying and it is present in GMAIL, with the fixed element that shows the name of the following sender, when opening a long discussion.

[Nicolò Chieffo (yelo3)]

Still present in firefox 2.0.0.8, ubuntu gutsy.
see this webpage!!!
http://www.oakparkfoundation.org/

I have both nvidia and ati products. both hardware with either opensource and proprietary drivers act in this way. so the problem should not be caused by drivers

[Hussam Al-Tayeb (hussam)]

(In reply to comment #174)
> Still present in firefox 2.0.0.8, ubuntu gutsy.
> see this webpage!!!
> http://www.oakparkfoundation.org/
>
> I have both nvidia and ati products. both hardware with either opensource and
> proprietary drivers act in this way. so the problem should not be caused by
> drivers
>

The situation in firefox3 alpha9pre is a lot better. Although the bug is still there but it appears in less websites than in firefox2.
For example http://www.oakparkfoundation.org/ works for me but the bug still appears in some other sites also with an increased Xorg-server memory usage.

http://meyerweb.com/eric/css/edge/complexspiral/demo.html works pretty fine as well.

[Nicolò Chieffo (yelo3)]

Yes, the situation has improved with firefox 3 alpha9pre, I can confirm.
but only for some sites
for example these sites still do not work:
http://jove.prohosting.com/~l3ert/Fixed/test5.html
http://themes.wordpress.net/testrun/

[Bugzilla-dogtoe (bugzilla-dogtoe)]

Please be sure when you link to the wordpress themes site you link to http://themes.wordpress.net/testrun/?wptheme=701 and not http://themes.wordpress.net/testrun/ as users without the "cookie" set to the appropriate theme will likely get the default "Kubrick" theme which doesn't have the issue. The theme in question is one with a static background+alpha level transparencies not the indigo blue esthetically pleasing theme.

[Fondacio (fondacio)]

I've been following this bug for quite a long time. I used to experience it a lot, but after some hardware upgrades many of the pages linked here, as well as the testcases, scroll at an acceptable speed (current setup: WinXP Pro SP2, P4 3.0 GHz with hyperthreading, GF 6600GT, 1.5 GB RAM (although no difference with when I had 512 MB)). However, the following page is still extremely slow:

http://forum.viva.nl/forum/list_topics/1

Both IE7 and Safari hardly have problems with it. In IE7 the text jumps up and down similar to in Firefox, but not as much. Safari is really smooth. I'll try my Linux partition later but expect the same results.

[Milan-burda (milan-burda)]

I think that someone should actually start solving this nasty problem,
as it is obvious that it is a problem...
I don't see a point in posting even more reports that oh I can see it too...
It is a bug in the code, It doesn't matter which graphics card you have, ... etc.
As Windows XP is the biggest platform (Vista is afftected) too, it's quite serious.

[Bob-kateos (bob-kateos)]

As of Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007120900 Minefield/3.0b2pre This is still a major problem.

This page here, http://oops.opsat.net/doc/gtk/gtkwindow-hello-world.html when scrolled the blockquotes displaying code lag majorly, with potentially seizure inducing choppiness. The text scrolls fine, it is just the blockquotes which sort of jump out of the page when scrolled.

While the seizure part may be exaggerated, it does kind of hurt to look at it. It is worth nothing when the fixed is taken off the background, the problem does not exist at all. Occurs with smooth scrolling or not.

[Mark-slater (mark-slater)]

(In reply to comment #178)
> As of Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007120900
> Minefield/3.0b2pre This is still a major problem.
>
> This page here, http://oops.opsat.net/doc/gtk/gtkwindow-hello-world.html

Confirming choppiness almost to complete unresponsiveness on that page.

UA: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1

[cgohier (cgohier)]

http://www.cyberpresse.ca/ is scrolling well for me in Firefox 2.0.0.11, but scrolls very slowly with 3.0b1.

This is a very high profile newspaper site in Quebec.

[Roc-ocallahan (roc-ocallahan)]

This is *probably* a gfx issue over raw painting speed. Renominating based on regression reports.

[Mtschrep (mtschrep)]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2pre) Gecko/2007121107 Minefield/3.0b2pre ID:2007121107

See some choppiness here as well - once the whole page is scrolled scrolling up/down is fine.

[Jsfisher92 (jsfisher92)]

I've noticed in Debian that I have no scrolling issues with the Mesa driver, but I do with Fglrx.

This is with 2.0.0.8, Debian Testing, an ATI mobility x1400, and FGLRX 8.40.4.

[Rui Matos (tiagomatos)]

(In reply to comment #178)
> This page here, http://oops.opsat.net/doc/gtk/gtkwindow-hello-world.html when

Confirmed on Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b3pre) Gecko/2008012204 Minefield/3.0b3pre.

I've made a sysprof profile which shows that 95% of the time is spent on the X server (fedora 8's version with the binary nvidia driver v169.04).

Now, who's the fault? I tend to think that gecko should be choosing the requests it does from the underlying graphics system and try to not tax said system too much. Of course such is easier said than done :-) and there is obviously the possibility that X and/or the driver are at fault here.

[Bugzilla-dogtoe (bugzilla-dogtoe)]

(In reply to comment #178)
> This page here, http://oops.opsat.net/doc/gtk/gtkwindow-hello-world.html when

Confirmed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11.

Scrolling the page on Windows yields about 25-50% CPU, and lots of Window redraws (so much in fact its difficult to read the page unless the page is not scrolling). Note, this is probably different than the examples previously mentioned, where as they (on Windows) do not exhibit the same "painfully slow scrolling" as its Linux counterpart. However, comment #178 suggests a page that even in Windows is painfully slow.

Perhaps all of this is a more fundamental/core/Gecko related and not OS specific?

[T35t0r (t35t0r)]

Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2

Page in comment #178 is still really bad. I also get the same jittering/slow scrolling effect while viewing mails at gmail.com . Opera and konqueror are much smoother on these pages.

[Mara-chlup (mara-chlup)]

Created an attachment (id=303709)
Firefox 3b3 very very slow scrolling!!! (Firefox 2 scrolling fast)

"position: fixed;" is very importan for top menu on intranets. Browser is not good for intranets, when scrolling very very slow.

[Bugzilla3 (bugzilla3)]

(In reply to comment #98)
I'm afraid this testcase will be worksforme for many users. I, for, one, see the same behaviour (i.e. no problem) with FF 2.0.12 and FF 3.0b3 on Win XP, Core Duo 1.8GHz, Nvidia Geforce 7600GS (a run of the mill machine, for today's standards)

[Peter-vanderwoude (peter-vanderwoude)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008021623 Minefield/3.0b4pre ID:2008021623

all testcase WFM except the last one with the large/huge table, which isn't really this bug

[Joh-walt (joh-walt)]

Huh? Ok, no testcase but realworld page--what about: http://www.assoziations-blaster.de/info/Physiker.html
It's slooow in Seamonkey and FF (both recent trunk) and blazingly fast in Opera.

[Gandalf-aviary (gandalf-aviary)]

Huh?
Peter: how can you call it "not a bug"? The last testcase works extremely slow on Gecko trunk, and very well on Firefox 2.

If that's not a regression bug than what? "feature"?

[Pascalc (pascalc)]

the one with 100 positionned elements is definitely choppy and eats 100% CPU while scrolling (tested with Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9b4pre) Gecko/2008021404 Minefield/3.0b4pre ID:2008021404). Works perfectly on the same machine which has decent current hardaware (core 2 duo 2Ghz, 2GB ram, Nvidia 8400M card) with Firefox 2, so this is a performance regression.

[Peter-vanderwoude (peter-vanderwoude)]

(In reply to comment #102)
> Huh?
> Peter: how can you call it "not a bug"? The last testcase works extremely slow
> on Gecko trunk, and very well on Firefox 2.
>
> If that's not a regression bug than what? "feature"?
>
That testcase is a bug, but not this one.
Large tables suck when scrolled, it has nothing to do with position:fixed

[Pascalc (pascalc)]

The testcase that is performing badly for me is the one with 100 positionned transparent images, not the one with 100 positionned empty so it looks like it is not due to the positionning of elements but to the alpha channel of images.

[Gandalf-aviary (gandalf-aviary)]

(In reply to comment #104)
> That testcase is a bug, but not this one.
> Large tables suck when scrolled, it has nothing to do with position:fixed

Let me repeat. The testcase with huge tables works very well and smooth on Fx2. It scrolls choppy on recent trunk.
I call it a regression and even if there are other issues with big tables, this one is another to put on the stack.

[Gandalf-aviary (gandalf-aviary)]

I also tried to turn off position:fixed on the huge table testcase and it does help.

[Mara-chlup (mara-chlup)]

Created an attachment (id=303996)
Firefox 3b3 very very slow scrolling!!! (Firefox 2 scrolling fast)

Now, I attach new version - table is bigger and scrolling is slower. See Cpu usage and compare Firefox 3b3 with Firefox 2.

For user with ~1.5GHz CPU it is big problem! For Linux terminal server it is big problem!

"position: fixed;" is very importan for top menu on intranets. Browser is not
good for intranets, when scrolling very very slow.

[Vladimir Vukicevic (vvuk)]

We're not going to block on this -- we can't fix fixed background issues without Compositor, and things are better enough at this point.

[Zurtex (zurtex)]

Shouldn't a regression like this be blocking or something? It seems like a pretty big step back.

I'm told this is A LOT worse than Firefox 2...

[Bugzilla3 (bugzilla3)]

Indeed FF3 shows a scrolling performance regression for very large tables but it has nothing to do with THIS bug, as other posters already noted. Please look at bug #54542 which is a 'meta' bug for all large table perfomance issues. There are decent test cases in bug #54542 that would stress even modern machines. Perhaps you may open a new bug and make bug #54542 depend on it. I'm obsoleting the last unrelated testcase.

[U-contact-rowanw-com (u-contact-rowanw-com)]

I've discovered that the height of my browser window affects the scrolling performance, the shorter the window is the smoother the scrolling, the taller the window is the slower the scrolling.

I decided to try changing the height of my Firefox window by a few pixels at a time until the performance dropped to an unacceptable level (noticeable jerkiness), this ended up being roughly 820 pixels.

This was my test page: http://www.developmentseed.org/

Specs:
Minefield 3.0b4pre (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008030206 Minefield/3.0b4pre)
Windows XP SP2
Celeron CPU 3.06GHz
2GB of RAM
GeForce 7300 GS
Screen resolution: 1280x1024

[Brian Brunswick (brian-ithil)]

Very unfortunate that this bug also happens accessing gmail with the mozilla version in hardy alpha 6
Its effectively unusable!

[Dave (fehe)]

Here's a site that's really bad: http://www.theloudspeakerkit.com/shop/

[Matti-mversen (matti-mversen)]

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

[Bugzilla3 (bugzilla3)]

(In reply to comment #112)
> Here's a site that's really bad: http://www.theloudspeakerkit.com/shop/

The above testcase is worth examining and doesn't seem to be affected by factors unrelated to this bug.

[Marcus (marcus-noveis)]

Is this going to be fixed? It makes Firefox 3 unusable for me.
FF2 works fine though.
This really needs to be fixed.

[Roc-ocallahan (roc-ocallahan)]

I commited a fix in the last few days that should help some pages on Windows.

We have a separate fix that affects gmail scrolling on all platforms, it hasn't landed yet. It won't help when you have gmail chat windows open, though.

[Hans L (thehans)]

I can confirm this issue with Firefox 2.0.0.13 on Ubuntu Gutsy 7.10.

Previous attachment: https://bugzilla.mozilla.org/attachment.cgi?id=133309 is a good simple example that exhibits this issue for me.

[Hans L (thehans)]

I forgot to mention, I came across this bug after having issues mainly in Gmail, with the box showing the name of the sender in the next reply (mentioned in comment # 95), and also the "Loading..." box that shows at the top of the screen while loading a long thread.

Sorry for the double post.

[Fitdoc (fitdoc)]

(In reply to comment #182)

> See some choppiness here as well - once the whole page is scrolled scrolling
> up/down is fine.

Right after I launch Mozilla, scrolling is facile and even, but it seems to become erratic, especially when everything is graphics-intensive (like pages with fixed background or the mailer). As stated by others, "This is not something gradual -- the problem either is or isn't there, depending on some threshold of opened pages." I'm running Safari on the same pages well [Apple MacBook Pro w dual core processing and Mozilla 2.0.0.13 Firefox.]

[Subs-voracity (subs-voracity)]

Another slow scrolling page:

http://www.csseleven.com/

Strangely, it only scrolls slowly for me when the window width is just larger than the row of face pictures (when the window width is between about 950px and 1300px). If I reduce the width, or make it much larger, scrolling is fine.

[Johan Douma (johandouma)]

Created an attachment (id=315511)
Demonstration: html file with big tables + css file

[Johan Douma (johandouma)]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008041306 Minefield/3.0pre
But it's been like this on at least the few last builds.
I'm using Vista SP1, Core 2 Duo T7500 2.2, 2gig of ram, 8400gt.

I just added a new attachments which demonstrates the slow down.

The html file contains very large tables but speed is very good if there isn't a fixed div, so I don't think this is related to bug #54542.

With only one (unlike comment #105) fixed div in the page 2008041306 Minefield/3.0pre is really slow, whereas Firefox 2 doesn't have any trouble displaying this page, not slow down at all compared to minefield. Safari and Opera are faster than Firefox 2 on this page as expected.
Even if there is a lot of code, Minefield stops using resources as soon as the position of this div is changed. It's h2#dateTitle{ on line 424 in the css file.
Firefox 2 is a bit slower if that div has a fixed position but it's nothing compared to the slow down occurring in minefield.

I first thought it was the transparent png used as background but removing it didn't change anything (bug #105).

As Rowan said in comment #111, there is a big improvement when the window is resized to a smaller size, but with a lower height, about 500px, but that's probably normal as it's a lot smaller window and faster to generate.

I don;;t have any problem in gmail, as other poeple talk about it early but that's probably not related. Probably Bug #424915.
I don't know about minefield on mac, I'll have a look tomorrow.

[Mike DePalatis (depalatis)]

I also experience this problem with Hardy, Firefox 3 beta 5. In particular, gmail and google reader have very slow scrolling speeds (something like a half second delay between one move of the mouse wheel and the actual scrolling action ocurring).

[Christoph Roeder (brightdroid)]

Another example:

http://ajaxian.com/

The problem still exists in FF 3.0b5!

[Geeknik (geeknik)]

I do not see this behavior on Firefox 3.0 Beta 5. I'm on XP SP3, 4GB RAM(3.4 visible to the OS), 600GB RAID0 for my C:, 8800GT(512MB) PCIe Video, and an Intel Core2Quad Q6600(4x 2.4ghz cores) all held together by an Intel D975XBX2.

[Christoph Roeder (brightdroid)]

Sorry I forgot to write, I use Linux (Kubuntu 8.04, 64-bit) and have this system:

- Intel Core2Duo E8400 (on an MSI P7N Platinum)
- 4 GB RAM
- nVidia 8800 GTS 512

PS: I am not using the Kubuntu Firefox, I installed it by myself

[Fitdoc (fitdoc)]

The new beta seems to work better: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

[Lh-bennett (lh-bennett)]

This issue shows much in Win32 Vista and XP. Complaints at MozillaZine has increased about the issue.

http://forums.mozillazine.org/viewtopic.php?t=653791

Users report crippling scroll performance with multiple sites with fixed backgrounds. My machine also experiences this phenomenon with fixed background scrolling.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050706 Minefield/3.0pre ID:2008050706

Examples:

http://sga.gatech.edu/
http://www.gameswelt.de/
http://www.fm-zagorje.org/
http://www.cssmagazine.it/

[Thomas-lendo (thomas-lendo)]

I can confirm slow scrolling perfomance on Linux/Ubuntu with http://ajaxian.com/ and other sites, but http://www.cssmagazine.it/ is the worst site of all I ever tried with Fx3.

Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9pre) Gecko/2008050707 Minefield/3.0pre ID:2008050707

[Bugzilla-spray (bugzilla-spray)]

This bug has over 50 different example URL's (+ a testcase) where this bug can be seen. I think that should be enough not to post more "i see this here as well" comments.

[Rnicoletto (rnicoletto)]

Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050706 Minefield/3.0pre on Windows XP Pro SP2 with a clean Firefox Profile. Hardware: DELL LATITUDE D505.

1) cssmagazine.it - I can reproduce the problem using both auto-scrolling than smooth-scrolling.

2) ajaxan.com - I can reproduce the problem using smooth-scrolling BUT NOT using auto-scrolling.

3) fm-zagorje.org - I CANNOT reproduce the problem using both auto-scrolling than smooth-scrolling.

4) gameswelt.de - I can reproduce the problem using both auto-scrolling than smooth-scrolling.

5) sga.gatech.edu - I can reproduce the problem using both auto-scrolling than smooth-scrolling.

6) csseleven.com - I can reproduce the problem using both auto-scrolling than smooth-scrolling.

7) gtkwindow-hello-world.html - I can reproduce the problem using smooth-scrolling BUT NOT using auto-scrolling.

8) .cyberpresse.ca - I can reproduce the problem using smooth-scrolling BUT NOT using auto-scrolling.

9) mono-project.com - I CANNOT reproduce the problem using both auto-scrolling than smooth-scrolling.

10) oakparkfoundation.org - I can reproduce the problem using smooth-scrolling BUT NOT using auto-scrolling.

11) praxis-wiesbaden.de/start/sitemapfs.html- I can reproduce the problem using smooth-scrolling BUT NOT using auto-scrolling.

I noticed Firefox behaves different using only the mouse-wheel than dragging the scroll-bar (more "power consuming")

[Rnicoletto (rnicoletto)]

(In reply to comment #199)
> This bug has over 50 different example URL's (+ a testcase) where this bug can
> be seen. I think that should be enough not to post more "i see this here as
> well" comments.
>

But lots of those example URL's are no more valid or does exist no more (especially the old ones). Better stick with recent URL's as per https://bugzilla.mozilla.org/show_bug.cgi?id=90198#c199

[Syskin (syskin)]

Is scrolling part of PGO instrumentation? Perhaps if it was added, compiler could make things somewhat better, like it did with javascript.

[Mats Palmgren (matspal)]

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

[Kp-watzlawek (kp-watzlawek)]

I realized this bug in Firefox 3 RC1. The scrolling speed of Firfox 3 RC1 is very catastrophic if you use the "Fixed" attribute in a stylesheet after a big background image (1680x1050 Pixels).

I include 3 examples, which show the bug!

http://abiads08.ab.funpic.de/test123/index.html <-- attribut: Fixed, big background image --> slow

http://abiads08.ab.funpic.de/test123/index2.html <-- attribut: Fixed, samll background image --> fast

http://abiads08.ab.funpic.de/test123/index3.html <-- only big background image --> fast

<style type="text/css">

 body { background:#09aeff url(bg.jpg) fixed center; }

</style>

As you can see the problem appears only if you are using big background images with fixed attribute in CSS.

[Eugene Miller (theerm)]

For the record, I've had this problem in Firefox 2, 3b5 and 3rc1

In firefox 2.0.0.* if there is a fixed image like blog.the-erm.com has. Scrolling barely takes a hit, however in 3b5 scrolling speed is slowed down dramatically, and it's jerky in 3rc1 it gets much much worse. I couldn't handle using it for more than 5 min before I realized I better get used to 2. because I can't upgrade to 3 with this kind of performance hit. It's a pitty too, because I improvements to the browser bar. The net is my income, and one of the pages I have that makes me the $$ has such a div, If I started using 3, I'd loose hours out of my year waiting for the screen to update, and considering I don't get paid until the job is done. I'd be loosing time & money if I used 3.

I'm running kubuntu linux 8.04 in (kde 3.5.9). I haven't tested it in gnome.

But a fixed div with bottom:0; right:0; *really* makes it slow in 3rc1 so much so that I would consider running firefox3 to be a downgrade over firefox2. Some pages have this problem in firefox 2 because people are being stupid and have a big fixed background image on their page like myspace user always do.

[Johan Douma (johandouma)]

True, this is defenitly a regression, there is a huge difference between 2 and 3RC I posted here 6 weeks ago and nothing has happenned since. Worse Firefox is now RC... I hope this is going to be fixed. If not I'll be using Safari for a part of my work as one of the tools I used has a lot of tables+cells and fixed elements.
Please, I really like Firefox, don't leave this unfixed.

[Unknown W. Brackets (unknownbrackets)]

I really hate "me too" comments, and don't mean to make one here... but I have to say I cannot imagine Firefox 3 going out with this bug.

A lot of sites, including MySpace pages as some have noted, blogs, etc. are affected by this bug. While it's true some may change things to workaround this bug - that's really bad from an evangelism perspective.

I know that it's already RC1, and I'm figuring honestly there's no chance for this bug. Worse, I'd try to help and make a patch or at least troubleshoot the code, but I really don't have time in the next few weeks to do so - just to complain. Still, I wish this was getting more attention - even if it has to be for 3.1... then I could tell people of the light at the end of the tunnel.

Thanks,
-[Unknown]

[Madjik (madjik)]

I don't see big problem on the exemple you give. But it seems that position:fixed causes FF3 a lot of troubles! 100% CPU and a big lag. :-(

We discuss it on a french board: http://www.geckozone.org/forum/viewtopic.php?t=65654

Try the given exemples:
http://actu.c4.fr/
http://csszengarden.com/?cssfile=http://www.s427.ch/divers/cssZenGarden/v02/sample.css
http://www.thestyleworks.de/quickref/index.shtml

[calmar (mac-calmar)]

It seems indeed to be much better now compared to how it was on that narrenschiff page - hardly to detect now even.

(in fact on http://actu.c4.fr/ the delay is obvious).

[Bugzilla-gtalbot (bugzilla-gtalbot)]

To those who comment(ed) and/or complain(ed) about this bug:

1- How many of you have smooth scrolling on?

2- "dead slow", "horrible", "unbearable", etc.. are very subjective adjectives which do not give any kind of accurate measurement, objective measurement, quantifiable data, comparable data like a performance profile comparison. 0.3sec could be deadly slow to you while 0.4sec could be just fast enough to person_B. We have no idea here. How big is the gap between horribly slow and fast enough in milliseconds? We have no clue, no idea, not even an hint. And we have to compare (and to assess) all these measurements regarding respective hardware, configuration, os, settings, etc... involved.

3- How long is a long table or a very long table? "very long" is still vague, not quantifiable, non comparable, non-specific, not really useful ... and I'm not even mentioning nested tables, deeply nested tables and over-excessively formated tables for layout purpose here..
"scrolling performance regression for very large tables but it has nothing to do with THIS bug". Dimitrios, comment #110

4- How many of you are mentioning webpages which have hundreds of validation markup errors, CSS errors, regarding webpages which can not in any way constitute a reduced testcase highlighting the issue in this bug?

5- How many of you are mentioning webpages that have lots of images, which are Flash-intensive, Flash-dependent, with a very large and deep DOM tree of nodes, with divitis and classitis, with thousands of javascript lines of code spread into several script files and functions, abusing setTimeout and setInterval, with generated content (like ads rotating, iframe refreshed), in over-constrained layout, over-excessively defined constraining stylesheets for pixel-perfect layout, etc.?

6- How many of you are mentioning webpages which would be considered - anyway and regardless - CPU-demanding, RAM-demanding, video-memory-demanding and user-system-resources demanding according to today's standards? How many of those webpages are already pushing the limits a bit far to begin with?

7- "'position: fixed;' is very importan for top menu on intranets": Do intranet webpage require 100 fixed elements?

8- How many of you are referring to characteristics which should be reported in other bugs (bug 90198, bug 64401, bug 202718, bug 54542, etc...) and not in this bug?

9- How many of you have read
What is a Simplified Test Case, and How Do I Make One?
http://www.mozilla.org/newlayout/bugathon.html#testcase

10- How many of you have read
How to Really, Really Help Developers on Bugs -- Minimal Testcases
http://wiki.mozilla.org/MozillaQualityAssurance:Triage#How_to_Really.2C_Really_Help_Developers_on_Bugs_--_Minimal_Testcases

11- How many background images (tiled) constitute the fixed background regarding the mentioned webpages? You do understand that one big image in the background is quite different from having 1px by 1px image repeated+tiled all over the canvas... Anyway, why such issue is mentioned in this bug and not instead bug 90198 .. if that is needed?

12- How many of you have actually read the Bug writing guidelines?
http://developer.mozilla.org/en/docs/Bug...

[Madjik (madjik)]

> 1- How many of you have smooth scrolling on?

Without, it's a little better, but 100% CPU anyway.

I think this bug https://bugzilla.mozilla.org/show_bug.cgi?id=400230 is a duplicate. I posted a few examples of lagging sites in it.

[Madjik (madjik)]

For me the worst is http://www.thestyleworks.de/quickref/index.shtml
Very, very slow!

[Unknown W. Brackets (unknownbrackets)]

(In reply to comment #122)
> To those who comment(ed) and/or complain(ed) about this bug:
>
> 1- How many of you have smooth scrolling on?
>
> 2- "dead slow", "horrible", "unbearable", etc.. are very subjective adjectives
> which do not give any kind of accurate measurement, objective measurement,
> quantifiable data, comparable data like a performance profile comparison.
> 0.3sec could be deadly slow to you while 0.4sec could be just fast enough to
> person_B. We have no idea here. How big is the gap between horribly slow and
> fast enough in milliseconds? We have no clue, no idea, not even an hint. And we
> have to compare (and to assess) all these measurements regarding respective
> hardware, configuration, os, settings, etc... involved.

Your comments are very long and I cannot answer all of the points, but I can answer these.

Let's use for a test case "http://www.tuaw.com/". The following builds of Minefield and Bon Echo will be used for comparison:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008052308 Minefield/3.0pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.15pre) Gecko/20080520 BonEcho/2.0.0.15pre

1. general.smoothScroll greatly aggrevates this bug. Since there is UI to turn this on, let's test with it enabled in both Bon Echo and Minefield, please. (note that the problem occurs with it off.)

2. Let us measure how long it takes to scroll to the bottom of this same page in Minefield and Bon Echo. I'm using a not-as-modest AMD 64 X2 3800+ w/2.0 gig of ram, a GeForce 7600 GT at 1280x1024, and XP SP2. We will preform this test by consistently scrolling the mousewheel. I'm timing using my iPhone manually.

Minefield (smoothScroll OFF): 00:08.2
Minefield (smoothScroll ON): 00:14.0
BonEcho (smoothScroll OFF): 00:07.1
BonEcho (smoothScroll ON): 00:07.2

However, Minefield in both cases gets a lot of shearing (a very distinct and definable phenonemon), whereas BonEcho is fine.

Now, this is not a reduced testcase as you say. Good point. Let's make it one. Go ahead and install Firebug in both browsers. For best results, use the same version of Firebug (1.1 or 1.2).

Open Firebug on the website, click "HTML", and then on "<body>". On the right, select the "Style" tab. Look for "background:", and click on it.

Change the value from:
#477CBD url(http://www.blogsmithmedia.com/www.tuaw.com/media/tuaw-bg.jpg) no-repeat fixed 50% 0pt

To:
#477CBD url(http://www.blogsmithmedia.com/www.tuaw.com/media/tuaw-bg.jpg) no-repeat scroll 50% 0pt

This removes the "fixed" scrolling being discussed here. Now, run the above tests again. You will notice a difference.

I imagine this may have to do with possible any of the following factors:
A. Screen resolution/browser size.
B. Length of page and number of elements overlaying background (most likely just height of elements.)
C. Size of background image (width/height.)
D. Positioning of the background image.

This is clearly a regression from Bon Echo (which had no problems here.)

-[Unknown]

[Bugzilla-gtalbot (bugzilla-gtalbot)]

@Unknown,

I commend your efforts to bring more formal steps to reproduce and more objective data/measurements (including possibly performance profiling) into this bug...

> Look for "background:", and click on it.
>
> Change the value from:
> #477CBD url(http://www.blogsmithmedia.com/www.tuaw.com/media/tuaw-bg.jpg)
> no-repeat fixed 50% 0pt
>
> To:
> #477CBD url(http://www.blogsmithmedia.com/www.tuaw.com/media/tuaw-bg.jpg)
> no-repeat scroll 50% 0pt
>
> This removes the "fixed" scrolling being discussed here.

... but all this is about background-position: fixed which is bug 90198, not this bug 201307. This 201307 bug shouldn't be far from being fixed if bug 203439 has been fixed. Again, I still think this bug should be resolved as WFM... unless someone can bring something real, concrete, reproducible, good testcase, etc... Who here experienced "slow scrolling" with attachment 139911 and with provided URL (http://www.w3.org/Style/Examples/007/scrollbars.html)?

Your post also identified how you scrolled (which is very good from a reproducibility perspective): you roll the mousewheel. You see, it could have been [PgDn], [PgUp], dragging scrollbar thumb up|down, clicking the scrollbar arrows or up|down key arrows...

------

@madjik

If smooth scrolling is ON, then it should be resolved as a DUPLICATE of
bug 202718 (Windows), bug 424308 (Mac), bug 409456 (Linux)

[Bugzilla-gtalbot (bugzilla-gtalbot)]

> preform this test
> by consistently scrolling the mousewheel.
>
> Minefield (smoothScroll OFF): 00:08.2
> Minefield (smoothScroll ON): 00:14.0

That has to be bug 202718, not *this* bug.

[Unknown W. Brackets (unknownbrackets)]

(In reply to comment #125)
> ... but all this is about background-position: fixed which is bug 90198, not
> this bug 201307. This 201307 bug shouldn't be far from being fixed if bug
> 203439 has been fixed. Again, I still think this bug should be resolved as
> WFM... unless someone can bring something real, concrete, reproducible, good
> testcase, etc... Who here experienced "slow scrolling" with attachment 139911 [details]
> and with provided URL (http://www.w3.org/Style/Examples/007/scrollbars.html)?

Ah, I confused this with that one (actually I thought they were the same, but now that I delve into my memory, I remember that there were two bugs after all.) Before I didn't care about that other one, because I thought it was reasonably fast.... then I forgot they were different bugs.

Sorry for the bugspam. IMHO, as a developer, I don't think this needs to be fixed at all for 3.0 or anything. Virtually no sites use position: fixed, it's not (or wasn't once) well supported across browsers anyway iirc.

That said, bug 90198 really is about a more general problem of it "being slow". Probably I'm looking for a more specific bug for this actual regression.

Sorry for the bugspam.

As for that attachment, it scrolls identically for me in Bon Echo and Minefield, and what's more, very quickly and without shearing. Again, I totally agree this bug is probably not a huge issue (and from the comments which I just looked over again, seems to find a lot of people confusing it with backgrounds.)

(In reply to comment #126)
> > preform this test
> > by consistently scrolling the mousewheel.
> >
> > Minefield (smoothScroll OFF): 00:08.2
> > Minefield (smoothScroll ON): 00:14.0
>
> That has to be bug 202718, not *this* bug.
>

Not really. I don't care about smooth scrolling. It's easier to reproduce using smooth scrolling (likely because of that bug) but I'm talking about the *recent* change in speed of scrolling with fixed backgrounds (compared to Bon Echo) whether smooth scrolling is enabled or not.

That bug is about both versions (and even older too), and I see shearing on the page it references even with my hardware and Bon Echo.

-[Unknown]

[Johan Douma (johandouma)]

Firefox 3 2008052304

(In reply to comment #122)

> 1- How many of you have smooth scrolling on?
Nope it's off.

> 2- "dead slow", "horrible", "unbearable", etc.. are very subjective adjectives
> which do not give any kind of accurate measurement
1 sec between redraws maybe

> 3- How long is a long table or a very long table? "very long" is still vague
6 tables of 62 columns, 15 lines each, no backrgrounds on the cells.

> 7- "'position: fixed;' is very important for top menu on intranets"
2 fixed divs

> 4- How many of you are mentioning pages which have hundreds of validation errors
> 5- lots of images, Flash-intensive, Flash-dependent, with a very large and deep
> DOM tree of nodes with thousands of javascript lines of code spread
> into several script files and functions, abusing setTimeout and setInterval,
> with generated content (like ads rotating, iframe refreshed), in
> over-constrained layout, over-excessively defined constraining stylesheets for
> pixel-perfect layout, etc.?
> 6- How many of you are mentioning webpages which would be considered - anyway
> and regardless - CPU-demanding, RAM-demanding, video-memory-demanding and
> user-system-resources demanding according to today's standards? How many of
> those webpages are already pushing the limits a bit far to begin with?

Yes that's the case.

Maybe it should be slow then... regarding the mess in the code. After reading comment #122 this slow down could definitly be normal and justified. And a few people have probably been convinced that it's not a firefox problem.

The code is a mess and is pretty heavy, there's a fixed div with a png background, and there a png background. It's slow. Without the images it's better but still slow.
So I actually have 2 'bugs' here at the same time. But both of them have a big impact on performance.

I'm posting this because Firefox 2 handles it perfectly fine.

Like W. Brackets did, comment #124, rolling the scroll wheel as fast as possible, the time it took to scroll from top to bottom of the page, retried, 3 or 4 times if any difference:

Smoothscroll on
FF 2 about 5, 6 seconds, slightly slower than whithout smoothscrolling.
FF 3 2008052304 took an astonishing 48 seconds the first time and 50 seconds the second time I tested it. Where 20 seconds are spent on the last 200px of the page. 8 times slower?
We knew already that smoothscrolling did that, but I didn't really expect it to be this bad. Redrawn once per second as well, not worse then with smoothscroll off, but the distance scrolled at each redraw is a lot smaller.

Smoothscroll off:
Firefox/2.0.0.11 20071127: between 3 and 5 secondes, redrawing maybe 4 or 5 times a second.
Firefox 3 2008052304 after trying several times: between 13 and 15sec to scroll from the top to the bottom, with about 1 redraw per second. About 3 times slower...

But I don't really see shearing, a slight bit, but far less than some other websites on internet somethimes.

I'm not using smoothscrolling anyway, I don't use it.

This has been tested on a G5 1.8ghz 2gig ram, some nvidia card... I'm at work at the moment. But on Vista SP1 core 2 duo 7500, 2gig ram, 8400gt, the result is the same, it's faster...

[Bugzilla-gtalbot (bugzilla-gtalbot)]

> Yes that's the case.
>
> Maybe it should be slow then... regarding the mess in the code. After reading
> comment #122 this slow down could definitly be normal and justified. And a few
> people have probably been convinced that it's not a firefox problem.
>
> The code is a mess and is pretty heavy, there's a fixed div with a png
> background, and there a png background. It's slow. Without the images it's
> better but still slow.
> So I actually have 2 'bugs' here at the same time.

Or maybe the position: fixed bug has been fixed.

> But both of them have a big
> impact on performance.

Correct and appropriate QA bug management indicate that we shouldn't confirm a bug unless a set of conditions are met, a good, clear testcase, thorough search for duplicate has been done, etc.

> I'm posting this because Firefox 2 handles it perfectly fine.
>
> Like W. Brackets did, comment #124, rolling the scroll wheel as fast as
> possible, the time it took to scroll from top to bottom of the page, retried, 3
> or 4 times if any difference:
>
> Smoothscroll on
> FF 2 about 5, 6 seconds, slightly slower than whithout smoothscrolling.
> FF 3 2008052304 took an astonishing 48 seconds the first time and 50 seconds
> the second time I tested it. Where 20 seconds are spent on the last 200px of
> the page. 8 times slower?
> We knew already that smoothscrolling did that, but I didn't really expect it to
> be this bad. Redrawn once per second as well, not worse then with smoothscroll
> off, but the distance scrolled at each redraw is a lot smaller.
>
> Smoothscroll off:
> Firefox/2.0.0.11 20071127: between 3 and 5 secondes, redrawing maybe 4 or 5
> times a second.
> Firefox 3 2008052304 after trying several times: between 13 and 15sec to scroll

Then that is bug 202718, not *this* bug. Discussion, data, comparison regarding smoothscroll ON or OFF should not be in this bug.

> The website where I get this is on the intranet.

Realistically speaking, there is nothing to be done without being able to examine, investigate, test, performance-profile a webpage. We still would need a reduced testcase focusing and targeting (and highlighting) well the performance + behavior considered as incapacitatingly slow.

> I will try to upload a new archive containing the images/html/css files,
> stripped from the private information.

Please consult

What is a Simplified Test Case, and How Do I Make One?
http://www.mozilla.org/newlayout/bugathon.html#testcase

How many of you have read
How to Really, Really Help Developers on Bugs -- Minimal Testcases
http://wiki.mozilla.org/MozillaQualityAssurance:Triage#How_to_Really.2C_Really_Help_Developers_on_Bugs_--_Minimal_Testcases

I believe that attachment 139911 and this bug's URL
http://www.w3.org/Style/Examples/007/scrollbars.html
were adequate webpage and testcase for this bug. If no one experiences significant (measurable) loss of performance in those webpages with a trunk build, then this bug should be resolved as WFM.

[Johan Douma (johandouma)]

@Gérard Talbot No offense but it looks to me as if you're trying to convince everyone that there isn't any bug. I do think there's is something with this position:fixed

I wasn't comparing smoothscroll.

Here are the results again, with smoothscroll off:
FF2: between 3 and 5 seconds, redrawing maybe 4 or 5 times a second
FF3: between 13 and 15 seconds, redraw once a second
that's 4 to 5 times slower.

I've posted an attachment already a few weeks ago, cleaned up from all the images only but not css. I know I should have created a simple file with a fixed div and some text... I did read the 'howto' file a bug and do tests, etc...

But in my case it's a bit complex. So please bear with me and maybe advise me on how to proceed with this case.

In this case:
I have a png in the background, and a png in the fixed div, and a hole lot of tables, lot of stuff styled... All together it's slow. See results above.
If I get rid of the fixed div. It's back to normal, it's not slowed down. This tells me I'm in the correct bug, and I'm not posting in the wrong place.
BUT with the fixed div:
If I get rid of the png backgrounds and keep the fixed div, it's still slow but a lot better. And when I get rid of all the css styles, then it's back to a normal speed. Speed difference slightly visible.

I know it really sounds like it's something else in the code that slows it down, but I've spent a few hours removing rules one by one to see if there was a performance impact. And it became better, gradually; I couldn't see any difference each time I removed a rule. In the end there wasn't much an impact between 'not fixed' and 'fixed'.

Concludion:
- Clean of images and css, difference slightly visible.
- Alltogether, css, images, etc... Big difference between the version that has the fixed div and the one that hasn't.

Now I'm only speculating on how this is possible...

in FF2, a fixed div might have a 50% performance impact... So between the version that may take let's say, 100ms, it will take 150ms if there is a fixed div.

in FF3, there might be a 500% performance impact.
So on the simple test case like attachment #139911 where it takes 10ms to draw without fixed div, it would take 50ms, with a fixed div. 50ms is not slow. The few attachment indeed do not have any significant loss of performance.
But if the page takes 100 seconds to be drawn without fixed div because it's damn complex, it would take 500ms to redraw with fixed div.

So no I will not post a testcase like attachment #139911, because it doesn't represent what I get. But i don't really have any other ideas to post a test case whitout all the css and images. Anybody has any ideas on how to create a test case for this?

[Marco Pivetta (ocramius)]

418948 seems to be a duplicate of this bug...
I've noticed that this bug also whenever "background-attachment: fixed;" appears in a CSS...
With FF3RC1 it has becomen a serious bug... framerate on my computer (Intel Centrino core 2 duo, 2 Gb of ram) has decreased to something around 4 FPS
The page where I noticed the most significant CPU usage is on my site:
http://www.stogame.net/wiki

[Bugzilla-gtalbot (bugzilla-gtalbot)]

> it looks to me as if you're trying to convince
> everyone that there isn't any bug.

I do not see a bug. I can not reproduce the problem when using a trunk build on windows. I can not reproduce the problem when trying all of the mentioned URLs so far, including this bug's provided URL http://www.w3.org/Style/Examples/007/scrollbars.html
and attachment #139911 . Now, if the bug is still happening on the trunk, then provide a testcase relevant and relative to this bug. Do you understand?

I am trying to convince you that several of the so-called URLs, testcases included in this bug were
- 404 not found
- redirected to nowhere
- abusing or depending on Flash
- abusing or depending on javascript
- have huge amount of coding errors, are examples of over-excessive formating, over-excessive coding, declaring, over-constrained layout,
- etc..

and that none of this serve the purpose of demontrating or reproducing or isolating a bug or faulty behavior or weak performance. If this bug still occurs, then at least a large minority of us should notice, measure something significant when trying attachment attachment #139911 or this bug's provided URL.

> I do think there's is something with this
> position:fixed

Fine! Then proceed accordingly with

What is a Simplified Test Case, and How Do I Make One?
http://www.mozilla.org/newlayout/bugathon.html#testcase

How to Really, Really Help Developers on Bugs -- Minimal Testcases
http://wiki.mozilla.org/MozillaQualityAssurance:Triage#How_to_Really.2C_Really_Help_Developers_on_Bugs_--_Minimal_Testcases

There are such things as the capability to reproduce a bug under controlled conditions, where we can compare data, examine testcases, use and compare (before fix and after fix) performance profiles, etc... Otherwise we shouldn't confirm a bug.

> I wasn't comparing smoothscroll.

Why do people in this bug keep mentioning smooth scroll then? Why can't you provide smooth scroll related data to respective bugs like bug 202718 (Windows), bug 424308 (Mac), bug 409456 (Linux)?

> Here are the results again, with smoothscroll off:
> FF2: between 3 and 5 seconds, redrawing maybe 4 or 5 times a second
> FF3: between 13 and 15 seconds, redraw once a second
> that's 4 to 5 times slower.

Which test case are you referring to? What's your overall system configuration for getting those data? I can not reproduce anything close to your data with this bug's provided URL http://www.w3.org/Style/Examples/007/scrollbars.html
and attachment #139911.

> I've posted an attachment already a few weeks ago, cleaned up from all the
> images only but not css. I know I should have created a simple file with a
> fixed div and some text... I did read the 'howto' file a bug and do tests,
> etc...
>
> But in my case it's a bit complex.

It is **NOT** just a bit complex. It's an 85 Kilo-byte HTML file (7598 lines of code, 86193 bytes!) with several linked (external and imported) stylesheets and several linked external javascript files that we can not see or examine with your RAR compressed file because your very long HTML file uses relative addressing, not absolute addressing. And I'm not even mentioning inline style, inline javascript cod...

[Unknown W. Brackets (unknownbrackets)]

Created an attachment (id=322577)
Simple test case with plenty of fixed divs (requires js.)

Here's an example that shows plenty of fixed divs.

Doesn't appear to be affected by using an image as a background or not. Greatly affected by smooth scrolling, but that's not this bug.

For me, performance is similar in Minefield and Bon Echo.

[Greg Campbell (glc-bugs)]

With this testcase, I detect a small amount of slowness compared to scrolling this bug report. I have a feeling it's dependent on system specs, but with my approx. 2-year old hardware it's barely detectable. With a 600 MHz PIII, it might be a different story.

One thing I notice is that the scrolling decelerates when it gets to the last 5 or so lines at the top or bottom of the page. This does not happen on a page without the fixed elements.

I see very similar performance with Fx2 and Fx3 RC.

[Mara-chlup (mara-chlup)]

FF2: Mozilla/5.0 (X11; U; Linux i686; cs-CZ; rv:1.8.1.12) Gecko/20080129 Iceweasel/2.0.0.12 (Debian-2.0.0.12-1)
FF3RC1: Mozilla/5.0 (X11; U; Linux i686; cs; rv:1.9) Gecko/2008051202 Firefox/3.0

Processor: AMD Sempron(tm) Processor 2600+
RAM: ~440 MB
OS: Debian with 2.6.25-1-686 kernel
Resolution: 1280x1024
general.smoothScroll: false

Scroll by arrow down key on keyboard.

attachment #139911 - only "box 1" is "lock (fixed)"
------------------
1) FF2:
   2s (scroll is fine and continuous; usage CPU: 57%)
2) FF3RC1:
   5s (scroll is brokenly; usage CPU: 100%)

attachment #303996
------------------
1) FF2:
   27s (scroll is fine and continuous; usage CPU: 57%)
2) FF3RC1:
   131s (scroll is brokenly; usage CPU: 100%)

[Mozilla-spam (mozilla-spam)]

@jose #199: When it's fixed, it's enough. This is a serious bug and a regression from ff2. No better way to say that than 205 comments of "me too".

[Jakub 'Livio' Rusinek (liviopl-pl)]

with smooth scrolling that's even bigger massacre :s .

[Bugzilla3 (bugzilla3)]

(From update of attachment 315511)
After properly reducing that testcase, I noticed that the only important factor in it is border-right:solid and border-bottom:solid properties of the cells. Therefore, it is irrelevant to this bug

[Gustavo Carneiro (gjc)]

I think this is fixed by Bug #219587.

[Cwwmozilla (cwwmozilla)]

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

[Gizz (gizz)]

I found this bug report when searching for problems on slow scrolling and fixed elements.

http://planetsuse.org/ produces *very* annoying slow scrolling effects; the site is barely usable (it gets even worse when zoomed in)

Hope this helps...

specs:
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0
Running Ati radeon mobility X600

[Jakub 'Livio' Rusinek (liviopl-pl)]

Same problem, but I have nVidia GeForce 6200.

Both with nv and nvidia (closed-source nVidia provided driver) have the problem.

[Madjik (madjik)]

It's correct on http://planetsuse.org/

Try this one: http://www.boobalechat.com/archive-06-2008.html
For me, it's the worst.

After seeing this, or http://actu.c4.fr/ or http://www.howtocreate.co.uk/fixedPosition.html (even fixed but smooth in IE6), I start moving on Opera... :-/

[Bugzilla3 (bugzilla3)]

(In reply to comment #139)
> Try this one: http://www.boobalechat.com/archive-06-2008.html
> For me, it's the worst.
Again, please read technical info already posted here before posting an irrelevant testcase. Especially read comment #125. What you see in your case is NOT this bug. It's bug #90198. (I don't notice performance problems with the rest of the links you mentioned so I won't comment on them).

[Bjg123 (bjg123)]

The worst offending site for me is ign.com, by far. The page is almost
unusable when viewed with Firefox 3 running on Windows Vista. Around the
internet, editing the usercontent.css is frequently suggested, but it made no
difference to me. Turning smooth scroll on/off also makes no difference, nor
did uninstalling/reinstalling flash. That's also problematic--some embedded
flash videos load very slowly or not at all.

Flash aside, the scroll is absolutely a critical bug to fix. Performance is MUCH worse than in either the current IE or the previous Firefox.

[Rick (rick2910)]

@Roberto Ramirez

WORKSFORME: ign.com runs perfectly normals and smooth over here. Firefox 3 with Windows Vista.

[Madjik (madjik)]

You're right, sorry. I follow them both.
Don't you think these 2 bugs have the same origin? Fixed = lag...

And even those with smooth scrolling listed on comment #125. Fixed = lag.

[Kataho-mail (kataho-mail)]

Created an attachment (id=326909)
a bit of position:fixed element and a bunch of resized images

[Kataho-mail (kataho-mail)]

A combo of any position:fixed elements and a bunch of resized images remarkably decreases frame rate. Check out attachment #326909 with Firefox3. Turn smooth scroll on and scroll up and down and see difference on responce between on upper side and on lower side. Upper side is filled with resized images and lower side is filled with raw ones. Our fixed element is only one black dot on upper right.

You may want to say that this is caused by resized images but a position:fixed element. If you can not be sure, comment this little dot out and see the performance turns to all just fine.

[Laubzega (thorgal-wfmh)]

Years ago (comment #21) I wrote that I suspected this bug was caused by offscreen pixmap allocation used by compositing operations required by pages with fixed elements/backgrounds. With NVIDIA Linux driver it is possible to force these pixmaps to video memory and presto, all testcases scroll very smoothly. Force them to system memory and they are dog-slow again. Respective commands are:

nvidia-settings -a InitialPixmapPlacement=2
and
nvidia-settings -a InitialPixmapPlacement=1

(documented here:
http://cgit.freedesktop.org/~aplattner/nvidia-settings/tree/src/libXNVCtrl/NVCtrl.h#n2797
)

In Opera this change does not visibly influence the scrolling speed - it is fast in both cases. This may mean following things:

a) Opera allocates (some of) relevant bitmaps in a way which ensures they land in video memory. This could be caused by their parameters somehow convincing the driver's heuristics to do the alloc in video memory.

or

b) Opera doing compositing in a more efficient way (less operations? different masking?)

The second option seems more viable to me, as Opera is still fast even when pixmaps are forced to system memory.

Can someone in the know tell me to where in Mozilla code compositing for pages with "fixed" elements is handled? Thanks.

[Jakub 'Livio' Rusinek (liviopl-pl)]

Sadly you can't control this with stock nv driver :/ .

[Roc-ocallahan (roc-ocallahan)]

Miloslaw: thanks for the info. Maybe Opera is doing all the compositing locally and just sending the final result?

[Roc-ocallahan (roc-ocallahan)]

background-attachment:fixed elements aren't drawn any differently from normal. The only reason that parameter makes a difference is that it means each time you scroll, we have to redraw the entire window instead of just the scrolled-into-view part. Because of that, it's expected and necessary that scrolling a page with background-attachment:fixed elements is slower than background-attachment:scroll.

The way we paint backgrounds is quite straightforward. We use cairo, and have the image in an xlib surface, and cairo tries to use Xrender to draw it to another xlib "backbuffer" surface, which gets drawn to the window at the end of our draw cycle. This is supposed to be the "right way" to do things but depending on the X server and the driver, it can be slower than just doing everything with the CPU in your own process.

The performance problem might actually be drawing text, though, or anything else that's on the page. This bug is actually far too broad, it's really a "painting is slow" bug :-(.

I want people to file new bugs on specific very slow pages, on specific platforms, and make them block this bug. Bonus points if you can simplify the page down to one or a few elements that are still slow. That's really the only hope we have of making progress here.

[Simon Ruggier (simon80)]

Do you mean that the entire page contents are redrawn, instead of just the part that is visible in the viewport?

[Roc-ocallahan (roc-ocallahan)]

No, just the part visible in the viewport.

[sabby7890 (tsalacinski)]

It seems that it happens only when the size is not set to default (no matter if the page is enlarged or shrinked). Scroll is very slow if there is any fixed element, and resizing the page slows it much more.

Firefox works very fast even on very complex websites without fixed elements. If I enter a basic website that contain at least one fixed element, it starts working slowly. If I will adblock an element (even floating "Hello" text), the website starts working properly.

For example, on OGame there is a fixed background. Scrolling is very slow. Adblocking the background speeds up the site (it just works so smooth that it can't be better).

Also I've noticed, that if the search bar on the bottom is active (the CTRL+F one), scrolling works slower (but still at acceptable speed). Closing the bar makes the page work lightning fast.

@Miloslaw Smyk

You are right, but on my computer this option slows down Firefox considerably (it works VERY slow on OGame site).

[sabby7890 (tsalacinski)]

Yes, I can agree. It's not because of large images, because they are handled properly. Mozilla works lightning fast even with very complex websites, but only if fixed elements are removed.

It's something that has to be fixed, as well as resizing pages (when you resize page once, after that it works properly, but it's very slow if you start resizing for the first time).

I think this can solve all performance issues with Firefox.

[Jakub 'Livio' Rusinek (liviopl-pl)]

> I think this can solve all performance issues with Firefox.

Nooo :> .

Add background with bg-attachment:fixed and transparent image on top.

It will be slow.

For example this is slow: http://blog.ninaque.com/

[sabby7890 (tsalacinski)]

Yes, as I said, this background is fixed. Removing it makes Firefox working fast again. That self-transparent logo on top doesn't seem to slow down the performance for me.

[Eugene Miller (theerm)]

This is a lousy fix, but it works.

When you move the mouse wheel, it hides the fixed div, so you can scroll, and then after a second of no movement, it'll show it again. I don't use the up/down arrows to scroll the page, so I didn't include an "onkeydown" window event, but it wouldn't be that hard to implement.

<style>
  #fixedDivId {
    position:fixed;
    right:0px;
    bottom:0px;
    border: 1px solid #000;
    background: #FFF;
  }

</style>

<div id="fixedDivId">I'm fixed.</div>

<script type="text/javascript"><!--

var hideTimer = false;
window.addEventListener('DOMMouseScroll', hideFixedDiv, false);

function hideFixedDiv(e){
 document.getElementById('fixedDivId').style.display = 'none';
 if (hideTimer) {
  clearTimeout ( hideTimer );
 }
 hideTimer = window.setTimeout("document.getElementById('fixedDivId').style.display = ''; hideTimer = false;", 1000);
}

//-->
</script>

---- Same thing only in jquery, and using a class.

<style>
  ,fixed {
    position:fixed;
    right:0px;
    bottom:0px;
    border: 1px solid #000;
    background: #FFF;
  }

</style>

<div class="fixed">I'm fixed.</div>

<script type="text/javascript"><!--

var hideTimer = false;
window.addEventListener('DOMMouseScroll', hideFixedClasses, false);

function hideFixedClasses(e){
 $('.fixed').css('display','none');
 if (hideTimer) {
  clearTimeout ( hideTimer );
 }
 hideTimer = window.setTimeout("$('.fixed').css('display',''); hideTimer = false;", 1000);
}

//-->
</script>

[Nicolas Loeuillet (nloeuillet)]

hi there!

is there any modification i can make on my code?

Thanks!

[Bugzilla-spray (bugzilla-spray)]

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

[Bugzilla-spray (bugzilla-spray)]

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

[Márcio Vinícius (marvinmep)]

Hi, my friends... I was making some tests here - trying to discover why Firefox' appearance is so different (and uglier) from Windows to Linux - and could notice something about this problem here:

A profile created in Windows works better in Linux (scrolling pages) than one made by default in Linux itself. I copied the paste of my profile in Windows and used the copy within Linux and now the scrolling is a little faster.

I don't know if this information can help, but it is one more thing to consider.

BTW, don't you thing this bug has lasted for too long? It is here since 2001 (7 years ago!) and apparently nothing changed.

I can't code, I only can beg you to help. It passed the time to take an effective action to solve this problem. Someone has to take this problem to himself and dedicate all efforts to solve it. This community bug hunt isn't working anymore here.

We all know that Mozilla likely don't care too much about Linux, but what I just can't understand is why Firefox can't be same in Windows and Linux. Opera (i.e.) is exactly the same software in both SO, the same in appearance and in way of work.

I must confess I really considered to move to it and give up Firefox. Unfortunately (or not) I must be not the only one to think this way.

Obs1: I know this problem (slowly scrolling) happens in both SO (I don't know about Mac), but it is much more obvious in Linux.
Obs2: And it happens scrolling through mouse wheel or scroll bar.

[Junk-jiv (junk-jiv)]

I guess I'm not really surprised that this is still open, and I'm even less surprised that it's gotten so confused in comments.

I wonder if it wouldn't be more helpful to open a new bug that targets this problem very specifically and doesn't have 5 years of confusion hampering it?

In any case, I'll try to summarize the problems that have been brought up and their status as far as I know:

1. Performance is worse when a page has fixed ELEMENTS (i.e. not a fixed background). Performance decreases as the number of fixed elements grows. I believe this is still an issue and will include my evidence in the following comment.

2. Performance was worse when a page has the background-attachment: fixed CSS property applied. This problem is bug 90198. It is AFAIK totally unrelated to the current bug, and it seems that it doesn't generally affect people anymore.

3. On Windows, performance was worse when other windows were on top of the Firefox viewport. This seems to have been fixed since comment 24.

4. I think there's a problem where having opened enough images, pages, or other applications causes a sudden and drastic drop in scrolling performance (see bug 90198 comment 21). This is what I was talking about in comment 6, and haven't since been able to reproduce. It is NOT this bug.

5. Any slow/CPU-intensive scrolling is more so with smooth scrolling enabled. This is either common sense or a different bug, depending on your viewpoint.

6. Slow scrolling with large tables is bug 421601 and is totally unrelated, except that they can be used to emphasize the perf difference between a page w/ and w/o fixed elements.

7. Slow scrolling with resized images is bug 163975 and is totally unrelated, except that it can be used to emphasize the perf difference between a page w/ and w/o fixed elements.

Did I miss anything?

If we're going to leave this open, let's just focus on THIS bug and stop getting hung up on the other things that exacerbate it.

[Junk-jiv (junk-jiv)]

Regarding the slowdown encountered when scrolling pages with fixed elements (item 1 in the prior comment) ONLY:

This is apparently still an "issue" on my machine. Here's how I tested:
With smooth scrolling off;
Scrolling by holding down the Down Arrow key on the keyboard;
On a system w/ WinXP, Athlon 64 X2 6000+, nVidia GeForce 8800GTS;
Under build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1;

Using attachment 133309 w/ static menu, (0 fixed elements) CPU usage is ~0%.
Using attachment 133309 w/ fixed menu, (1 fixed element) CPU usage caps at ~4%.
Using attachment 170761 (100 fixed elements) CPU usage caps at ~11%.

It is my opinion (@Gérard, Dimitrios) that the above testcases are simplified and demonstrate this problem effectively. I do not believe that there is a need for any additional testcases on THIS BUG. Some later testcases make this behavior more apparent by combining it with other problems (attachment 326909), but are not really necessary.

I can't say whether the above performance numbers are acceptable or unacceptable; it only demonstrates that the engine must do much more work to render pages with fixed elements.

This isn't a problem for me since I have a very powerful computer, but (particularly when exacerbated by the other bugs mentioned above) may be a problem for older or less capable computers like the EeePC or iPhone.

[Subs-voracity (subs-voracity)]

I appreciate this will only be sorted by filing/fixing multiple bugs, but I just wanted to note that I'm seeing this issue more and more in day-to-day browsing. Here's an example of a recent site I'm having issues with (but there are many more):

http://au.sports.yahoo.com/olympics/

I get very choppy scrolling on my Dell Inspiron 6400 (Dual Core 1.73GHz) with ATI Mobility Radeon X1400 graphics, whether or not powerplay is enabled. On my desktop (Core 2 2.1GHz with Nvidia 7600GS), scrolling is fine (there appears to be a little lag, but it's hard to see).

This is with Fx3 and Fx3.1 nightly. Fx2 with these sites scrolls fine.

[Andrei Eftimie (andrei.eftimie)]

Confirming this issue ( http://au.sports.yahoo.com/olympics/ ) on
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

Also http://fronteers.nl/congres/2008/english
(for reference: casual browsing, scrolling problems more often then FF2)

[Hceylan (hceylan)]

I think I have a clue for the reason some people here experience this problem as a small problem but some as a big problem. The reason is, the bigger the viewport, the worse the the situation is.

I have a Core 2 Duo 2,6GHz CPU, 4 GB RAM, nVidia Corporation Quadro FX 1600M (Tried both closed source / open source drivers W/ 3D available / not available) laptop. That is a monster laptop. The screen resolution is 1920x1200. Computer is running Fedora 9 / 10.alpha W/ Gnome. I tried 2.22 & 2.23 gnome / gtk versions.

Firefox is Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008072301 Fedora/3.0.1-1.fc10 Firefox/3.0.1

Now, I get very different performance between the states Firefox maximized and Firefox is 800x600 sized.

The sample site is http://dev.xwiki.org/xwiki/bin/view/Main/
The values are given for 800x600 | ~1920x1200 window sizes.

Below are the comments for the QA

> 1- How many of you have smooth scrolling on?

off | off

> 2- "dead slow", "horrible", "unbearable", etc.. are very subjective adjectives
almost no lag | 10 sec
> 4- How many of you are mentioning webpages which have hundreds of validation
Only 2 HTML errors with '&' are not escaped as '&apm';

> 5- How many of you are mentioning webpages that have lots of images, which are
N/A

> 6- How many of you are mentioning webpages which would be considered - anyway

No

> 7- "'position: fixed;' is very importan for top menu on intranets": Do

Only 1 fixed div

> 8, 9, 10, 11, 12

Now, I have got an objection here. Do the users, trying to help you out here, have to be the QA people for Mozilla or does Mozilla have a bunch of QA people, who can constitute good test cases out of information available. People, I see here are positively trying to help Firefox solve this issue. I think rather then storming at them, the time and efforts put by them should be appreciated.

Rather then expecting them to have the QA approach, expecting them to answer further questions should be enough.

And one last note I do not know excatly what that means but here is an excerpt from the bug header:
"QA Contact: Hixie (not reading bugmail)"

Regards,
Hasan Ceylan

[Rene Herman (rene.herman)]

My main bug entry is 372039. Most information at #30 there.

But just to get the information here as well -- I'm on Linux, screen size does not seem to matter and there's nothing subjective about "unbearably slow". Trust me; after letting go of the scrollwheel, it can even take up to 10 real seconds for it to stop scrolling. Smooth scrolling is off.

The webpage I'm mentioning as one of the very clearly affected ones:

http://www.bnrmetal.com/v2/search.php?name=black+sabbath

(all band pages there).

Given that I'm quite decidedly not a web-designer, I suppose there are better candidates for enumerating its properties.

With Firefox 2.0.0.15 (to which I've retreated due to this issue) some laggyness can also be observed there but it's much better; in the sense that I hadn't even noticed it before Firefox 3 appeared and undeniably pointed out the problem

The "on Linux" bit may be relevant or not; I haven't a Windows box to test this with. Box on which I am with Linux is (as said in the other bug) an AMD Duron 1300 which is probably slower than most Firefox 3 users use and might account for me seeing the issue at all sizes and on many sites.

Opera 9.5 is lightning fast on all of them by the way.

[Junk-jiv (junk-jiv)]

For what it's worth, under my setup (see comment 150) the above site uses 40%, then 20% of the total processing power on my machine during scrolling (it changes about 1/4 of the way down) and has a very noticeable back-and-forth visual jerk at the bottom.

I realize completely that such a live site without a reduced test case (which we already have) isn't very useful. But, it's an interesting real-life example of how this issue and others can collide to yield exceptionally poor performance.

[Hceylan (hceylan)]

Is anyone working on this bug?

With this bug, along with the bugs this bug blocks, firefox becomes unbearably slow.

This is even true for the "Do you want to save password" pop up header animation at the top that appears when you log on to a site.

The test cases and examples given in this bug and the ones this blocks are all related to either fixed backgrounds or fixed div elements, meaning all down to fixed elements.

Most other browsers I tested with those sites are rendering the sites pretty well.

I kindly ask the firefox development team to boost the resources on this bug, so we can continue to use our beloved firefox comfortably . Otherwise I think most of the users will have no chance but to look for alternatives...

Regards,
Hasan Ceylan

[Michaell+bmo (michaell+bmo)]

(In reply to comment #221)
> Is anyone working on this bug?

Not as such. See comment 212 - this is basically a meta bug now:

> I want people to file new bugs on specific very slow pages, on specific
> platforms, and make them block this bug. Bonus points if you can simplify the
> page down to one or a few elements that are still slow. That's really the only
> hope we have of making progress here.

[Roc-ocallahan (roc-ocallahan)]

I have made a lot of progress in another bug related to this. That should be fixed soon, then we can revisit this.

[Hceylan (hceylan)]

Thanks for the comments Robert...

I hate to push too much, but any idea for a date to release a fix..?

[Mozilla-spam (mozilla-spam)]

bug 427431 offers a possible solution. Have any of the Linux devs looked into that?

[Mardeg (mardeg)]

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

[El3000 (el3000)]

(In reply to comment 212)

Not sure if I should report this as a separate bug, but here's a specific page and a specific platform that scrolls very slowly.

http://www.twitter.com/home

Steps to reproduce

1) REgister for a Twitter account
2) "Follow" several Twitter users to populate your twitter.com/home page with several entries
3) Scroll twitter.com/home

Problem: very slow scrolling
Expected: normal scrolling

Platform: vista sp1 86x
firefox 3.0.4

[sabby7890 (tsalacinski)]

User-Agent: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2

The full page zoom introduced a performance problem on Linux machine (problem doesn't exist on a Windows machine).

The problem is, that in overall, firefox gets slow if the page size is not at the default using full page zoom.

For example, try going to the URL I've provided and try to move the widgets on the right side. If you're at default zoom level, it superfast.

If you'll try to zoom though, it starts to work slow. No matter, if you zoom in or out.

Some pages start to scroll jerky (while at default zoom level scrolling is superfast on every website I've seen - I am talking about Firefox 3.0.4, not the beta I am using, because it works the same). Some pages start to be less responsive on "hover" elements. The known fixed div problem is happening only on not-default zoom level.

Basically, Firefox works great only on default zoom level. After zooming - the performance of some elements is dropped.

This doesn't happen if "Zoom text only" option is enabled. It seems to be related to scaling images. If the website doesn't contain any images, it scrolls/works/renders as fast as normal.

Reproducible: Always

Steps to Reproduce:
1. Go to url provided
2. Try to move the widgets on the right
3. Zoom in or out using full page zoom and try to move the widgets again
4. You can try also iGoogle (www.google.com/ig - you're not moving any images, only widgets drawn with css, but the performance is still slow)
Actual Results:
Overall performance is dropped when full page zoom is enabled and the site is zoomed.

Expected Results:
Firefox should behave the same no matter what is the zoom level.

This is not a problem with my setup (because I worked on many Linux machines and all behave the same, no matter if this is intel/nvidia/nv/ati driver).

Even if I'll shrink the page to the smallest possible (so widgets are taking only few pixels of space) - it's still slow.

[sabby7890 (tsalacinski)]

By the way - it might be leaking memory? After resizing the website to the smallest size possible, restoring the default zoom level doesn't help. Restarting Firefox helps.

[Mozilla-spam (mozilla-spam)]

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?

[Balzer (balzer)]

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 2.6.27.7-9-default, 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

FF2.0.0.20:
 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.

[Mardeg (mardeg)]

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

[Rickgregory (rickgregory)]

@225 - that page is different for everyone since it's a user specific Twitter home page.

The page ia VERY slow on my machine and has a large fixed background image:

http://whatever.scalzi.com/

It's speedy on Safari, a bit slow on FF 3.0 and moves about one line per second on Shiretoko nightlys.

Computer Info:

Macbook Core Duo, 2g RAM. Intel GMA onboard video (64M). Shiretoko 3.1b3pre (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090130 Shiretoko/3.1b3pre).

All addons disabled, though this did not perceptibly affect things.

[Zéfling (zefling)]

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

I use a complexe CSS menu on my website ( http://ikilote.net ) 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.

[Eugene Miller (theerm)]

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.

[From-bugzilla2 (from-bugzilla2)]

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?

[Rene Herman (rene.herman)]

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

[Absorbb (absorbb)]

(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.

[sabby7890 (tsalacinski)]

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 (https://bugzilla.mozilla.org/show_bug.cgi?id=468726).

[From-bugzilla2 (from-bugzilla2)]

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.

[Roc-ocallahan (roc-ocallahan)]

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.

[sabby7890 (tsalacinski)]

(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.

[Roc-ocallahan (roc-ocallahan)]

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

[sabby7890 (tsalacinski)]

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):

http://trac.webkit.org/wiki/HackingGtk

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).

[Roc-ocallahan (roc-ocallahan)]

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

[sabby7890 (tsalacinski)]

(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!

[trustin (trustin)]

@226 - I can also confirm the specified web site - http://whatever.scalzi.com/ - is extremely slow. It takes about a second to scroll a couple lines. My screen resolution is 2560x1600 and therefore the performance impact might be greater than lower resolution system. However, Opera just performs very fast with the same configuration, so I don't think this is a hardware problem.

This issue is still here in the latest nightly build:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090325 Gentoo Firefox/3.6a1pre

[Crowderbt (crowderbt)]

This is blazingly fast for me, in a currently nightly, fwiw. (on Mac OS X)

[Nicolò Chieffo (yelo3)]

Also for me in linux that site is ok. not smooth at all but definitely fast (it skips to visualize things when scrolling, but it's fast)!

[Crowderbt (crowderbt)]

I think this might now be Linux-only.

[Rickgregory (rickgregory)]

The latest nightly is better (about a line per 0.5sec) but is still dramatically slower than FF 3.07 on this Macbook. Dramatically meaning about 3-4x slower.

Note, BTW, that I can move down the page faster, but what I'm specifically doing is arrowing down (equivalent to clicking and holding the down arrow in the scrollbar). If I grab the page indicator in the scrollbar and move it up and down it's a bit hesitant, but acceptable.

[sabby7890 (tsalacinski)]

For me, on Linux, the sites mentioned in previous comments work actually pretty well. I am using:

Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.9.0.7) Gecko/2009030503 Fedora/3.0.7-1.fc10 Firefox/3.0.7

All sites are working a little bit slower than usual, but they still work very smooth. I believe that this is because of new NVIDIA drivers. I remember that on older driver versions (prior to 180.xx) I've experienced this bug. But I can't tell which version of Firefox I was using then.

[Roc-ocallahan (roc-ocallahan)]

<email address hidden>: have you zoomed that scalzi page? How's performance at the default zoom level (cmd-0)?

I suspect the scalzi site slowed down because it has a large tiled background image, and we changed our tiled image drawing to go through a temporary surface in some cases to avoid artifacts when zooming. But that should only happen when zooming is happening.

[Rickgregory (rickgregory)]

Robert....

Nailed it. For some reason the site by default comes up zoomed in one level. Setting it to default makes the performance fine, zooming back in degrades it again (unless the background isn't displayed because of the zoom level/window size combo).

Thanks.

[sabby7890 (tsalacinski)]

Confirming that when site isn't on default zoom level it works painfully slow. Need to wait few secs to scroll 5-7 lines.

[Absorbb (absorbb)]

Robert O'Callahan..
Hm. There are users that use zoom on all sites. For example it's me. I surf websites on 42" flat panel - and have to use zoom.
But fixed background not so rare thing. Sites that i use which very slow when zoomed:
http://lxj.endofinternet.net/kde/
http://wii.ign.com - terrible slow, but on latest trunk it is little faster then on 3.0.7

[sabby7890 (tsalacinski)]

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!

[Tyler Downer (tyler-downer)]

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.

[Mardeg (mardeg)]

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

[Virus-found (virus-found)]

Btw, I can't reproduce this on Linux with driver xf86-video-radeonhd 1.2.5-1. Scrolling works without any lag on both of testcases (tried with different zoom levels). Tough, when I was on Win XP with official ATI drivers, I could reproduce this without any doubt.

[Zéfling (zefling)]

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

[sabby7890 (tsalacinski)]

Hello,

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.

[Pascal de Bruijn (pmjdebruijn)]

I rechecked with Ubuntu Karmic and Firefox 3.5.3, and the website just works fine. This bug can be closed.

[Hilario J. Montoliu (hjmf) (hmontoliu)]

Thank you Pascal for your feeback

I'm closing this bug report as it seems to have been fixed in the mean while

[Ryanvm (ryanvm)]

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

[Roc-ocallahan (roc-ocallahan)]

When bug 564911 lands we should reexamine all testcases and linked bugs --- most of them should be fixed.

[Bugzilla-x-0x (bugzilla-x-0x)]

I guess you meant bug 564991

[Roc-ocallahan (roc-ocallahan)]

Yes indeed, sorry!

[Aja+bugzilla (aja+bugzilla)]

Looking good with 4b0436a4faf8 tryserver build.

[Sciguyryan (sciguyryan)]

The scrolling on this testcase seems to be smooth since retained layers landed. Roc, would you like to mark this one as fixed?

[Roc-ocallahan (roc-ocallahan)]

No, I would like you to mark this (and other bugs that are fixed) as fixed :-)

[Sciguyryan (sciguyryan)]

Very well. I just thought since you did all the hard work, you should get the pleasure of making these bugs fixed.

-> Fixed.

[Ryanvm (ryanvm)]

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

[Quynhld2 (quynhld2)]

I have been trying to find a way to fix this error on Mozilla Firefox to access https://kingnghiemso.com sharing many good computer tips.