Extremely sluggish scrolling

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

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)

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.

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.

->layout

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.

->kmcclusk based on comments.

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

Changing summary to something more explicative :)

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)

Changing summary to something more explicative :)

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

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

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

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

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.

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.

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.

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

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?

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

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

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

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

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

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

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.

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.

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.

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.

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.

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

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.

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

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

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.

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

 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.

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

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

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

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

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

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

Maybe you laptop with Vista OS
and desktop with XP.

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

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

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

I think this bug is tied to slow zooming on Linux and slow performance when zoom level is not at default (https://bugzilla.mozilla.org/show_bug.cgi?id=468726).

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

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

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

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

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

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

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

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

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

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

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

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

@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

This is blazingly fast for me, in a currently nightly, fwiw. (on Mac OS X)

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

I think this might now be Linux-only.

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.

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.

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

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.

Confirming that when site isn't on default zoom level it works painfully slow. Need to wait few secs to scroll 5-7 lines.

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

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

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

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

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.

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

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.

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

When bug 564911 lands we should reexamine all testcases and linked bugs --- most of them should be fixed.

I guess you meant bug 564991

Yes indeed, sorry!

Looking good with 4b0436a4faf8 tryserver build.

The scrolling on this testcase seems to be smooth since retained layers landed. Roc, would you like to mark this one as fixed?

No, I would like you to mark this (and other bugs that are fixed) as fixed :-)

Very well. I just thought since you did all the hard work, you should get the pleasure of making these bugs fixed.

-> Fixed.

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

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.