All users were logged out of Bugzilla on October 13th, 2018

When going to several sites scrolling is very slow - can be fixed by pressing the grayed out stop button.




18 years ago
18 years ago


(Reporter: heejaf, Assigned: dcone)


(4 keywords)

crash, perf, platform-parity, top100

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta3+]Fix in tree...[pdtp1], URL)


(1 attachment)



18 years ago
When going to the page scrolls very slowly. This can be fixed by 
pressing the stop button (even thought it's grayed out). Although this is most 
evident at, I think there is a general performance bug here. 

To see this, go to any site with a lot of pictures. Scroll the page up and 
down. Now rate the smoothness of the scrolling on a scale of 1 to 10. Now press 
the grayed out stop button. Once again scroll the page and rate the 
performance. I don’t know about you, put I always rate the scrolling speed 
better after pressing stop.

There is also another bug here. After pressing stop and scrolling the page up 
and down, parts of the page are missing. This can be seen at and

After all is said and done I think there are really three bugs here:

1) The stop button is active even though it’s grayed out
2) There is something going on in the background that is slowing the page 
rendering down. Pressing the stop button will end this behavior.
3) After pressing stop and scrolling, parts of the page are missing.

P.S. As this happens on a large site ( and also seems to be a 
general performance bug, I’m rating the severity as major. These bugs are 
present in the latest build (ID number 2000082108).


18 years ago
Keywords: top100


18 years ago
Ever confirmed: true

Comment 1

18 years ago
stop button being greyed out prematuraly, is now bug 49773

Comment 2

18 years ago
um, doesn't even have a scrollbar for me.  

Comment 3

18 years ago
Asa: give me your monitor and get a smaller one.

I don't see this bug, however.

Comment 4

18 years ago
Sk3, what build are you using? What OS?

Comment 5

18 years ago
082108 Win98.

Comment 6

18 years ago
What happens on your system?

Comment 7

18 years ago
Nothing out of the ordinary - page loads fine as it should and always has.

Comment 8

18 years ago
bleh. If you want someone to look into this bug, please build a better 
testcase. Using my awful xserver and netscape 4.7 solaris intel and mozilla 
[todays tip] the performance seemed about the same.

If you want to make a useful testcase, I suggest you find a nice image 
directory (about 65k as an html file) where each image is 1024x768. To load a 
page like this (where s/a href/img src/) takes about 900mb of ram [it's a good 
performance test], scrolling of this page on netscape4 or ie5 under windows2000 
when I made the test last spring was pretty good [1gb of VM was avail to the 
os, anything less reaked havok on linux and other boxes].

I will perform a test like this when I return to my nice ethernet connection, 
but at 26.4 I'm not going to spend the time or effort.

In general if you want a bug like this to be seriously considered please follow 
the bug reporting guidelines and use the bugzilla 

Resolving worksforme because i don't experience any significant scrolling 
issues on either or
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 9

18 years ago
Here's a nice page with lots of images. Removing top100 keyword.  If you feel 
that scrolling through this page is poor, well... I guess we need a way to 
judge that, but once we come up w/ a way, you can compare it to whichever other 
browsers you choose.

*** WARNING *** recommended ~1GB of VM and 256+MB of RAM.  HTML file is ~65k of 
pure <IMG   
SRC="">  <!--
Aka 1024x768 JPGs inlined.  IMO It's really a nice stress test.

I have not tested mozilla on this page, I will.

Comment 10

18 years ago
I think I was wrong about the cause (lots of pictures). I really dont have a 
freaking clue why it's doing what it's doing. But I think I need to restate how 
bad the problem is for me. When I click on the bottom scroll button tt takes 
over 4 seconds to move the page down! This is beyond slow, it CRAWLES!
Resolution: WORKSFORME → ---

Comment 11

18 years ago has the same problems that has on my system. Currently 
trying to find the common element. Will report back when I have something.

Comment 12

18 years ago
OK, I am seeing this now. Scrolling on is pretty slow and choppy, but
after pressing the disabled stop button, scrolling is much more smooth. Heejaf
may have found the root of the problem. However, after pressing the stop button,
some odd action occurs with scroll bars and drop down menus. Filing separate bug
on that.
Summary: When going to the page scrolls very slowly, can be fixed by pressing the grayed out stop button. → When going to several sites scrolling is very slow - can be fixed by pressing the grayed out stop button.

Comment 13

18 years ago
I'm told that the bug on the scroll bars has already been filed, so nevermind
this. CC trudelle about this. XP Toolkit/Widgets?

Comment 14

18 years ago
Created attachment 13468 [details]
Test case for slow scrolling

Comment 15

18 years ago
The slow scrolling seems to be caused by a major performance bug when 
overlaying images on top of each other. All the sites that have scrolling 
problems for me are caused by this (,, and others). 
Maybe somebody should look at this code? In the attachment that I have just 
added is a small testcase that has an image set as background, and another 
image overlaid on top of it. Also in the file is a text file with more 

Like previously stated on my comments, the testcase will be very slow scrolling 
in Mozilla. Pressing the stop button (even thought it’s greyed out) will make 
the scrolling much faster. Pressing the stop button seems to keep Mozilla from 
rendering the background image (and also creates other problems). You will see 
this after scrolling from the top to bottom (after pressing stop), the 
background will be GONE! As this means that Mozilla will not need to use the 
VERY slow code for overlaying images (my only reason for saying this code is 
slow is my theory about the cause of the problem), scrolling will be smooth 
again. What do you think?

PS Re-adding top100 keyword

PPS I seem to have messed up the attachment. To download it, use the right 
click and save as technique.
Keywords: top100

Comment 16

18 years ago
over to imagelib, if it's not theirs then maybe layout or networking maybe.
Assignee: asa → pnunn
Component: Browser-General → ImageLib
QA Contact: doronr → paw

Comment 17

18 years ago
On which OS are you seeing this ? 

Comment 18

18 years ago
I'm seeing this on Win98. Seems only me and sk3 have comfirmed the bug, and 
we're both on Win98, could this be platform specific? Anybody on a different OS 
care to take a look?

Comment 19

18 years ago
I believe that this is isolated to Win32, so adding pp keyword. If someone else
confirms on another platform, please update info.
Keywords: pp
Hardware: All → PC

Comment 20

18 years ago
Here on linux I don't see the bug, the scrolls are ok.

Comment 21

18 years ago
 I am seeing this too.
Windows 98
Build ID: 2000082513

Comment 22

18 years ago
My 1st guess is this has more to do with compositing
than image decoding. I'm going to run it by Kevin.
Assignee: pnunn → kmcclusk
Hitting the stop button (even through grey'ed out) is stopping the animated 
gif's on the page. Stopping the animated gif's speeds things up.

The background not being displayed is already covered by bug 49222.

This bug should cover the performance issue only. 

Adding perf keyword
Keywords: perf

Comment 24

18 years ago
Please look at my test case. There is not a single GIF in there, and yet the 
problem still shows. The performance issue has absolutely nothing to do with 
animated GIFs. If you looked at my test case you would see that the performance 
issue has to do with an image being overlaid on top of a background image. The 
same thing happens in the test case no matter what image format is used, both 
animated and still.

P.S. I hope the above is not rude. I'm quite mad at somebody right now, and I 
fear that that will show through in this message. If you take it as rude, I'm 
quite sorry.
This performance problem is caused by the image tiling code.
Currently it creates an enormous (1600 pixel X 1200 pixel) offscreen each time 
it is going to render the tiled background, then it releases it. On my home 
machine with 256Meg of memory it starts swapping to disk. 

If nsRenderingContextWin::CanTile(nscoord aWidth,nscoord aHeight)
is changed so it returns PR_TRUE, performance is excellent.

If we can't use PatBlt we need a solution which does not create massive 
offscreens  with each paint request.

We should also optimize the code in nsCSSRendering to at least intersect the 
rect to be painted with the damagedrect. The nsContainerFrame is passing an 
large rectangle to be painted, which could be cut down dramatically if the 
damaged rect where interesected with it. The rectangle passed by the 
nsContainerFrame is the used to create the large offscreen.

putting on nsbeta3 radar because of the memory bloat issue and poor performance.

CC'ing dcone.

Don, Why did you change the CanTile code changed to always return PR_FALSE?
Keywords: nsbeta3


18 years ago

Comment 26

18 years ago
I understand that the tiling code is quite bad, but why does it get so much 
worse when another image is added?

Comment 27

18 years ago
I have fixed this and a few other tiling bugs.
1.)  This bug was because the background image was very large, so every 
repaint a huge offscreen was being made.  I fixed this by checking for the size 
of the image.. if it was larger than the largest buffered tile.. the image was 
just blitted.. in this case just once to the screen.
2.)  I also make sure the size of the total tile needs to have a buffered tile.. 
this will cut down on time spend building a buffered tile when one is not 
3.)  This check also allowed fixed the PatBlt bug on NT.  So now NT can use the 
PatBlt for all background tiling.  
4.)  I think the PatBlt can be used for 95,98 and 2000 with tiles smaller than 
8x8.. I will have to run my tests first.  I will check in as soon as I get a 
code review.. probably on 9/10 or 9/11..

Tiling should be very fast now.. with a small number of changes.  Very 

Future improvements could be made by caching the new "buffer tile" .. so these 
buffers need only be created once.
Assignee: kmcclusk → dcone
Whiteboard: Fix in tree...


18 years ago
Changed priority to P1 and added crash keyword.

On platforms that don't have a large amount of memory, the existing tile code 
will cause crashes. 
Keywords: crash
Priority: P3 → P1
Marking nsbeta3+
Whiteboard: Fix in tree... → [nsbeta3+]Fix in tree...


18 years ago
Whiteboard: [nsbeta3+]Fix in tree... → [nsbeta3+]Fix in tree...[pdtp1]

Comment 30

18 years ago
adding pdtp1.  We agree with P1 status.

Comment 31

18 years ago
This is now fixed.. Limited the size of the Tiling buffer(fixes stability), 
limited the size of the background images that can use the Tiling buffer (fixes 
slowness), fixed some logic for doubling the tiles into the tiling buffer(fixes 
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 32

18 years ago
Updating QA Contact
QA Contact: paw → tpreston

Comment 33

18 years ago
Verified on build 2000092908
You need to log in before you can comment on or make changes to this bug.