MASTER - slow scroll with image as background-repeat

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

Product should be PHOENIX

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

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

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

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

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

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

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

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

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

The program that causes the slowdown, on my machine, is a java-based text editor
(jEdit; 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?

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

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

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

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

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

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

I hope this helps :)

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

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

That is extremely helpful. Thanks!

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Other comments:

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sorry!

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.

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

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+

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

For FF 3.1b2:

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

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

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

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

Test system: Just upgraded my laptop to openSuSE 11.1 (kernel 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.

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

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.

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!

is this bug the main origin of the extrem slow scrolling issue?
as mentioned in
https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/217580

this is an example website
http://stinkt.kicks-ass.org/1b6cc1af2e8437646c9b7422d78e6eb3/slidecast%20-%20studio%20-%20vertical-view.html

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

http://stinkt.kicks-ass.org/1b6cc1af2e8437646c9b7422d78e6eb3/no_css_fix_pos.html

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

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

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

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

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.