Closed Bug 96088 Opened 24 years ago Closed 23 years ago

scrolling on actiontrip page is slow

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: dev+mozilla, Assigned: waterson)

References

(
URL
)

Details

(Keywords: perf, platform-parity)

Attachments

(1 obsolete file)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3+) Gecko/20010815 BuildID: 2001081504 Scrolling on this page is really slow and uses a lot of CPU cycles. Other pages Reproducible: Always Steps to Reproduce: 1. Load page. 2. Scroll with cursor keys or scrollbar. Actual Results: Slow scrolling. CPU time goes up. Expected Results: Smooth fast scrolling and hardly any CPU use.
Keywords: perf
WFM on linux build 2001081715
*** Bug 96959 has been marked as a duplicate of this bug. ***
wfm linux 2001082408. Probably windows only.
Scrolling / rendering gets even slower when I leave a window over Mozilla window. For example if I open Task Manager in Windows 2000 which is set to be always on top and scroll the Mozilla window.
Another page that scrolls very slowly: http://www.eon.si/
*** Bug 97938 has been marked as a duplicate of this bug. ***
Adding pp keyword.
Keywords: pp
*** Bug 94821 has been marked as a duplicate of this bug. ***
another example - http://www.w3.org/Style/CSS/
http://www.w3.org/Style/CSS/ doesn't have a table in it. changing component to layout and reassigning to dbaron.
Assignee: karnaze → dbaron
Component: HTMLTables → Layout
http://www.w3.org/Style/CSS/ is slow cross-platform, and is unrelated to this bug (it's slow because of fixed positioning). All the others appear to be Windows-only (I don't see problems on Linux, anyway). Giving this to waterson since I think he has a copy of quantify on Windows, so he could at least point fingers at someone else. :-) If anybody wants to make a reduced testcase, that might be useful, if such a thing is possible...
really giving to waterson
Assignee: dbaron → waterson
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.5
Blocks: 100951
I'll attach a small testcase for fixed positionning that I wrote a while ago for another bug. It might be easier to work with than some of the pages listed above.
Attached file fixed positioning testcase (obsolete) —
Pierre: eh? This bug is about some (apparently) Win32-specific problem, and doesn't have anything to do with |position: fixed| elements AFAICT. Also, the test case you attached works fine for me on Linux and Win32 (i.e., no noticable scrolling performance problems). I'll try it on a Mac tomorrow. I'd recommend we open a separate bug if there is a problem scrolling with |position: fixed| elements on Mac.
See [David Baron 2001-09-16 09:08], which is why the bug got reassigned to you. It's been a known XP problem for a while. It is still there on the Mac as well as on Win98 (tested with Build# 2001-09-18-03). Edit a local copy of my testcase to compare the scrolling with and without the fixed positioned elements.
Sigh. Did _you_ read dbaron's comment? He says: http://www.w3.org/Style/CSS/ is slow cross-platform, and is unrelated to this bug (it's [the W3C page] slow because of fixed positioning). Perhaps you confused the referent of "it's", which refers to the W3C page, not this bug. None of the test cases (except yours, now) have any fixed positioned elements in them. Furthermore, dbaron says: All the others [dup'd URLs] appear to be Windows-only (I don't see problems on Linux, anyway). So, it's pretty clear to me that this bug is about platform-specific scrolling problems on Win32, not about cross-platform scrolling problems with fixed position elements (which your test case doesn't illustrate, AFAICT). So please file another bug if you are seeing problems with scrolling fixed position elements. Thanks.
Attachment #50564 - Attachment is obsolete: true
Allright, after _all_ that hubub, I've finally gotten around to trying some of the URLs listed in the bug on Win32 and am not noticing scrolling problems in a current build. Specifically, I've tried: http://www.actiontrip.com/previews/civilization3.phtml http://www.actiontrip.com/archives.phtml http://www.slo-tech.com/ http://www.eon.si/ Is this still perceived to be a problem?
Yes! The first of your URLs causes very sluggish scrolling on win32 2001092503 on win2kpro-sp2
Hrm... 1. How about the other URLs? 2. Could you send me details on your system config (CPU, memory, video card)? 3. Do you have the Flash plugin? (If so, could you try removing it and see if it makes a difference?) I've tried this on two different Windows machines, one an ancient Compaq Deskpro running Win98 on a 166MHz PII, the other an HP Vectra running Win2K on a 1GHz P4. On the slower box, the above pages definitely lagged sometimes, but no better or worse than any other graphics-intensive page (like home.netscape.com or www.cnn.com; e.g.) I had the Flash plugin installed on both machines.
1. How about the other URLs? Same except for http://www.slo-tech.com/ which seemed fine. 2. Could you send me details on your system config (CPU, memory, video card)? PIII 750MHz 384MB ATI Rage II Pro 3. Do you have the Flash plugin? (If so, could you try removing it and see if it makes a difference?) Yes. Don't know how to remove it, moving the plugins directory didn't do it.
I'm going to untarget; I need some help from QA to reproduce a configuration where these pages scroll unacceptably relative to comparable pages.
Keywords: qawanted
Target Milestone: mozilla0.9.5 → ---
FYI, I'm in the same boat. All of them except slo-tech.com scroll slowly for me. This is a 933 mhz p3 w/ 512mb ram.
Here's another slow page: http://www.landoverbaptist.org/ Have animated GIFs been ruled out as this page has no flash that I can find.
Ah! Good thinking. cc'ing pavlov and saari, who may be able to comment on that theory. Specifically, that animated images may be giving us hardware-specific grief.
(taking the risk of making a fool of myself again on this bug...) There is a severe problem with animated gifs described under bug 95431.
Pierre, the last time I checked, things like hampsterdance worked just fine, and there are no severe animated GIF performance problems that I'm aware of with the notable exception of crappy performance in less than true color (32bit) mode. Anyone have a Quantify run on these issues? That would be the best start. People who are having issues, in addition to your hardware, I need to know what color depth you're running in. If it is less than true color (32bit) then I already know what your problem is. If not, then we need more investigation.
32-bit.
16bit color depth.
blake, could you snarf one of the slow pages, strip the animated GIFs and see if that is the issue? Or do a Quantify run?
lohphat@earthlink.net, you're life is going to suck in 16bit mode until I find time to do a fairly large chunk of work. Go to 32bit if you can, you'll be much happier.
It's better but not great.
lohphat, could you try the same think I asked of blake, remove the animated images and see if that is the issue?
I had a look at the reported page and these comments apply only to that page and not to the other pages noted. The url http://www.actiontrip.com/previews/civilization3.phtml has a background image for the <body> that is a 1600 x 686 GIF. That has a decoded size (reported) of 3.4MB. I think that basically crowds out other images from the cache. When I scroll down the page, I can see the disk activity light on my PC flashing away (can even hear the disk grinding). This page is particularly bad as it also uses a lot (~15) of table background images (which must be tiled, and in case of a memcache miss, read from disk and decoded [if I understand things correctly]).
... er, and removing that body background cures a large part of the sluggish scrolling (although I wish there were a more quantitative way to describe what people are experiencing subjectively).
The landroverbaptist page also has an enormous background image. For me, the slo-tech page is not sluggish (how are people doing this scrolling: dragging thumb, click in gutter, click on scrollbararrow?). The eon.si does have a curious lag, where the thumb will move, but the view of the page is not updated for a fraction of a second. It does not have a huge background image, so it's some other mechanism, although it is entirely usable on my win2k box, so it's not really a priority to find a specific fix, IMO.
That would imply that pinning the current pages items in the cache is broken. Even if the contents of your current page exceed the image cache size, they should all be memory resident until you load a different page, to prevent issues just like this. Pavlov, does the background image handling do the right thing with regard to pinning items in the cache?
So a new question for the people seeing the problem, what is your memory cache size set to? I personally have mine cranked up since I have a lot of ram and that helps performance. Try cranking it up to 10MB and see if scrolling improves. Just trying to narrow down the problem for certain...
mem cahce = 10MB, disk cache = 0
Oops, I may have been slightly mistaken about my 'crowding out' suggestion. I was checking about:cache in the same window that I was loading the actiontrip url. If I do about:cache?device=memory in a second window, I can see that all the unique URLs for that page are held in the memcache, even when that amount exceeds the ~4MB default quota for the cache. However, my earlier statement about see substantial disk hits while scrolling still stands. Removing the background image improves the scrolling behaviour, and removes the disk hits. Setting the memcache quota to 16MB may improve scrolling behaviour, but does _not_ remove the disk hits (which begs the question: if everything in the page is in the memcache, what is it reading from disk?).
allright, time to see why we're hitting the disk (maybe later today, maybe tomorrow)
(I may be completely off once more but...) Bug 94758 describes a problem where a large image generate several huge temp files and lots of disk grinding.
Mock up test pages, identical except for presence of body-background image: http://jrgm/bugs/96088/page-with-bgimage.html http://jrgm/bugs/96088/page-without-bgimage.html
Well, bug 94758 scrolls smoothly for me. (cache: mem=10MB, disk=0)
Bug 94758 appears to be a different beast, in that the URL for this bug has a problem on win32, but seems "OK" on the Mac, while the URL for that bug is "OK" on win32 (and doesn't generate those temp files), but freezes the browser and does generate those temp files on the Mac.
Is there some relation to bug 96633 ?
Another URL: http://www.sfgate.com/weather/ Mostly *.gifs, one *.jpg, and one form element. Here's another interesting item: When you view the page info and click on the image Urls in the image tab, they don't display in the lower portion of the dialog, but only flash once, however some images do persist as expected. I'll see if there's an open bug on this...
Summary: scrolling on this page is slow → scrolling on actiontrip page is slow
scrolling on this URL appears to be down from 100% CPU on win platform thanks to checkin for bug 98252. stay tuned to #98252 for mac performance.
and background images performance rendering problems are in bug 99924, and bug 110113.
Is sloww scrolling on http://www.limewire.com/ the same bug or is this another bug?
Target Milestone: --- → Future
I tried all reported links in this bug and only two remeain sluggish for me: http://love.zinzanni.org/T_siteMap.html http://www.eon.si/ Using Mozilla 2002020208 on windows XP Pro.
this appears to be fixed, 2002-2-21-03 w2k, probably bug 122996. not seeing any slow scrolling anymore.
original URL appears to be fixed, 2002-2-21-03 w2k, probably bug 122996. not seeing any slow scrolling anymore.
I think it is not fixed yet. Almost all page scrool OK. But if you try to scroll user comments at the bottom of the page there is still not OK. Also try to move a small window accross user comments and this part does not refresh as nicely as other parts of the page.
Status update: This page WFM on 2002050504 win32 on win2kpro.
Marking WFM for the original URL using a 2002050408 trunk build on Win2k. If there are still URLs that scroll slowly, they should go into separate bugs.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: