All users were logged out of Bugzilla on October 13th, 2018
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).
stop button being greyed out prematuraly, is now bug 49773
um, www.nbc.com doesn't even have a scrollbar for me.
Asa: give me your monitor and get a smaller one. I don't see this bug, however.
Sk3, what build are you using? What OS?
What happens on your system?
Nothing out of the ordinary - page loads fine as it should and always has.
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
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
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.
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!
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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.
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.
I'm told that the bug on the scroll bars has already been filed, so nevermind this. CC trudelle about this. XP Toolkit/Widgets?
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.
over to imagelib, if it's not theirs then maybe layout or networking maybe.
Assignee: asa → pnunn
Status: REOPENED → NEW
Component: Browser-General → ImageLib
QA Contact: doronr → paw
Chris: On which OS are you seeing this ? -p
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?
I believe that this is isolated to Win32, so adding pp keyword. If someone else confirms on another platform, please update info.
Hardware: All → PC
Here on linux I don't see the bug, the scrolls are ok.
I am seeing this too. Windows 98 Build ID: 2000082513
My 1st guess is this has more to do with compositing than image decoding. I'm going to run it by Kevin. -p
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
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?
I understand that the tiling code is quite bad, but why does it get so much worse when another image is added?
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.
Assignee: kmcclusk → dcone
Status: ASSIGNED → NEW
Whiteboard: Fix in tree...
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.
Priority: P3 → P1
Whiteboard: Fix in tree... → [nsbeta3+]Fix in tree...
Whiteboard: [nsbeta3+]Fix in tree... → [nsbeta3+]Fix in tree...[pdtp1]
adding pdtp1. We agree with P1 status.
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).
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
Updating QA Contact
QA Contact: paw → tpreston
Verified on build 2000092908
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.