Closed Bug 29840 Opened 25 years ago Closed 24 years ago

scrolling by press-and-hold scrollbar arrow unusably slow on Moviefone.com

Categories

(SeaMonkey :: General, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

RESOLVED FIXED
Future

People

(Reporter: ekrock, Assigned: eric)

References

()

Details

(Keywords: perf)

On Moviefone.com's list of local films playing, scrolling down by pressing and holding the scroll bar's down arrow is unusably slow (much more than 30x slower than 4.72). Here was my test setup: a) HW: HP Omnibook 4150 P2-300 w/ 256M memory b) OS: WinNT 4.0 SP4 c) Nav4.72 and 3/1 Commercial (BuildID 2000022708--why diff from today's date?) To repro: 1) open above URL in both browsers 2) close all tool bars 3) resize two browser windows to be same size 4) One at a time, in each window: 4a) start with the scroll bar all the way at the top 4b) Put the mouse pointer over the scroll bar's down arrow. 4c) Press and hold the left button and stopwatch time to reach bottom of page I got these results: Nav4.72: 2.98 sec. 3/1 Commercial (BuildID 2000022708): it scrolled agonizingly slowly, getting slower and slower, and I finally gave up at 90 seconds only part way down the page Note: 1) This is *not* a DUP of bug 24956 (cnn.com scrolling 2x slower than 4.72 in Moz). The problems must be different because the performance gap between 4.72 and 3/1 Commercial is orders of magnitude worse on moviefone.com than on cnn.com. 2) It's also not a DUP of bug 19476, which seems to be focusing on a reported flickering problem in scrolling (which I didn't see).
Keywords: perf
Reassigning to kevin for evaluation.
Assignee: beard → kmcclusk
It does scroll slower than usual for me on WINNT, but not as slow as ekrock is reporting. If I grab the thumb and scroll it is very responsive so it's not a rendering performance issue. My guess is that the repeating timer used to control scroll incrementing is falling behind. Eric, can you take a look, since you implemented the gfxscrollbar button and repeat timers?
Assignee: kmcclusk → evaughan
I'm told this is because of style rule resolution. It should not be reresolving style for curpos, maxpos on scrollbars.
Status: NEW → ASSIGNED
Target Milestone: --- → M15
*** Bug 31131 has been marked as a duplicate of this bug. ***
*** Bug 24956 has been marked as a duplicate of this bug. ***
Mass-moving most M15 bugs to M16
Target Milestone: M15 → M16
CCd myself. Eric, I just saw your comments from 2000-03-21 11:50 and I agree with you. Stop by or give me a call...
In a sense this comment is just noise, but I have to say this is probably my number one issue with GFX scrollbars on the Mac. They're slow as molasses on a G4 400MHz so I can only imagine what they're like on a slow machine (unless its purely a throttling issue). This is with view manager 2. Switching back to native scrollbars cures the problem.
I no longer see the "unusably slow" bug on Commercial 5/5 2000050513 on WinNT4.0 SP4. I retested on todays list of movies for theater #039 at moviefone.com. Using the secondhard of my wristwatch, N6 seems just *barely* slower than Nav4.73 now on Win4.73 via click-and-hold scrolling using the scrollbar arrow. I'll doublecheck with my digital stopwatch at work, but I think this bug is either FIXED or darn close to FIXED. Copied lordpixel's previous comment to the Mac-GFX performance bug which is where it should go.
It is better, but still slow. moving to m18
Target Milestone: M16 → M18
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
(per trudelle). mass-moving all evaughan non-nsbeta3+ bugs to 'Future' milestone
Target Milestone: M21 → Future
fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.