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

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect, P1)

Description

[Chris McClelland]

When going to www.nbc.com 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 www.nbc.com, 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 
www.apple.com/quicktime and www.nbc.com.

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 (www.nbc.com) 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).

Comment 1

[jlarsen]

stop button being greyed out prematuraly, is now bug 49773

Comment 2

[Asa Dotzler [:asa]]

um, www.nbc.com doesn't even have a scrollbar for me.  

Comment 3

[Stephen Koren]

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

I don't see this bug, however.

Comment 4

[Chris McClelland]

Sk3, what build are you using? What OS?

Comment 5

[Stephen Koren]

082108 Win98.

Comment 6

[Chris McClelland]

What happens on your system?

Comment 7

[Stephen Koren]

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

Comment 8

[timeless]

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 
http://www.mozilla.org/quality/bug-writing-guidelines.html and use the bugzilla 
helper http://www.mozilla.org/quality/help/bug-form.html

Resolving worksforme because i don't experience any significant scrolling 
issues on either apple.com or nbc.com

Comment 9

[timeless]

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="http://www.macdesktops.com/images/1024x768/1984mov1024x768.jpg">  <!--
    -->
Aka 1024x768 JPGs inlined.  IMO It's really a nice stress test.

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

Comment 10

[Chris McClelland]

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!

Comment 11

[Chris McClelland]

www.nasa.gov has the same problems that www.nbc.com has on my system. Currently 
trying to find the common element. Will report back when I have something.

Comment 12

[Stephen Koren]

OK, I am seeing this now. Scrolling on nasa.gov 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.

Comment 13

[Stephen Koren]

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

[Chris McClelland]

Attachment: Test case for slow scrolling

Comment 15

[Chris McClelland]

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 (www.nbc.com, www.nasa.gov, 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 
information. 

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.

Comment 16

[Asa Dotzler [:asa]]

over to imagelib, if it's not theirs then maybe layout or networking maybe.

Comment 17

[pnunn]

Chris:
On which OS are you seeing this ? 
-p

Comment 18

[Chris McClelland]

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

[Stephen Koren]

I believe that this is isolated to Win32, so adding pp keyword. If someone else
confirms on another platform, please update info.

Comment 20

[Diego]

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

Comment 21

[Jeremy Wrinkle]

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

Comment 22

[pnunn]

My 1st guess is this has more to do with compositing
than image decoding. I'm going to run it by Kevin.
-p

Comment 23

[Kevin McCluskey (gone)]

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

Comment 24

[Chris McClelland]

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.

Comment 25

[Kevin McCluskey (gone)]

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?

Comment 26

[Chris McClelland]

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

Comment 27

[dcone (gone)]

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 
needed.
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 
optimized!

Future improvements could be made by caching the new "buffer tile" .. so these 
buffers need only be created once.

Comment 28

[Kevin McCluskey (gone)]

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. 

Comment 29

[Kevin McCluskey (gone)]

Marking nsbeta3+

Comment 30

[Michael La Guardia]

adding pdtp1.  We agree with P1 status.

Comment 31

[dcone (gone)]

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

Comment 32

[Paul Wyskoczka]

Updating QA Contact

Comment 33

[Terri Preston]

Verified on build 2000092908