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)
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).
Comment 2•25 years ago
|
||
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
Assignee | ||
Comment 3•25 years ago
|
||
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
Comment 8•25 years ago
|
||
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...
Comment 9•25 years ago
|
||
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.
Reporter | ||
Comment 10•25 years ago
|
||
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.
Comment 12•24 years ago
|
||
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
Comment 13•24 years ago
|
||
(per trudelle). mass-moving all evaughan non-nsbeta3+ bugs to 'Future'
milestone
Target Milestone: M21 → Future
Assignee | ||
Comment 14•24 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•