Closed Bug 148598 Opened 22 years ago Closed 22 years ago

very slow scrolling

Categories

(Core Graveyard :: GFX, defect, P3)

x86
Windows XP
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.2alpha

People

(Reporter: jevans, Assigned: dcone)

References

()

Details

(Keywords: perf, Whiteboard: [adt2])

Attachments

(5 files, 7 obsolete files)

2.50 KB, application/x-zip-compressed
Details
3.37 KB, image/png
Details
61.61 KB, image/jpeg
Details
5.79 KB, patch
kmcclusk
: review+
kinmoz
: superreview+
Details | Diff | Splinter Review
4.02 KB, patch
rods
: review+
kinmoz
: superreview+
Details | Diff | Splinter Review
100% cpu usage on all parts of the site. no problems in ie
p3 744, 512mb, tnt2
WFM, current CVS, Linux.

Reporter:
Please always include build ID in bug-reports.


-> GFX (?)

and confirming with win2k build 20020531.. (Athlon 1.2Ghz)

The scrolling is slow...

Assignee: Matti → kmcclusk
Status: UNCONFIRMED → NEW
Component: Browser-General → GFX Compositor
Ever confirmed: true
QA Contact: imajes-qa → petersen
Possibly a dupe of bug 133261.
WFM with build 2002052306 under Windows ME. I can't see any slow scrolling. 
Reporter, please try a newer build.
winxp build 2002060108
winxp build 2002060108
while loading scrolling is smooth
*** Bug 150078 has been marked as a duplicate of this bug. ***
-> dcone.

WFM: Using 6/7/2002 branch build on WinXP. Is scrolls smoothly.
Assignee: kmcclusk → dcone
It might scroll smoothly for most people if they have power house machines, but
anyting with a 1Ghz and lower will notice it.
Please try this again with the newest trunk build.. I put a fix in there that 
should clear this up.. I would think.  Also.. this is not a powerhouse cpu 
issue.. there are some graphics cards thats have a problems with some types of 
blits.. so we are in the process of fine tuning how this works.  For example the 
machine I work on.. is 400 mhz.. and it scrolls just fine.
I hope I got the right build because I don't notice a difference. Build ID:
2002061008, I'll try again tomorrow.
what build did you try that test on.
i have been trying it on nightly builds for weeks and 1.0
winxp, current build 2002061208
p3 744; 512mb; geforce4 (just upgraded from tnt2)
*** Bug 151204 has been marked as a duplicate of this bug. ***
*** Bug 150961 has been marked as a duplicate of this bug. ***
I can confirm the slow scrolling of the testcase.

1600*1200, duron 900, 512Mb, GeForce2 MX 32Mb, Win XP.
*** Bug 149224 has been marked as a duplicate of this bug. ***
Tryed with different resolution's and color depth - still slow. But with 16 bit
it's  faster than with 32 bit.
*** Bug 153949 has been marked as a duplicate of this bug. ***
Build: 2002061408 on Win2000, Cel466, Matrox G400

The slow scrolling is caused by the insane background image of e.g. 10x8000
pixels. Normal images of that size also cause degradation in scrolling
performance. Below 3 more links, the first 2 having a huge background image, the
3rd having a huge normal image. 

http://magma.nationalgeographic.com/ngm/data/2001/10/01/html/ft_20011001.2.html
http://www.sausagetools.com/professional/overview.html
http://www.splendorofflorence.com/LearningCenter/philadelphia.htm
*** Bug 150272 has been marked as a duplicate of this bug. ***
Severity: minor → normal
Depends on: 133261
Keywords: perf
*** Bug 152992 has been marked as a duplicate of this bug. ***
*** Bug 46942 has been marked as a duplicate of this bug. ***
here is the URL from the dupe
http://www.go-mono.com/class-status-System.html
Keywords: mozilla1.0+
Another slow scroller is about:config (build 2002061408) although I think this
is another problem than the insanse background problem.
Blocks: 100951
Keywords: mozilla1.1
Please retest your urls.. I have put in fixes for some other GIF problems and
scrolling seems to be much better on those.. it has fixed at least two choppy
scrolling bugs.
I still experience 'choppy' scrolling, for my system, on
http://bugzilla.mozilla.org/attachment.cgi?id=86381&action=view from 
http://bugzilla.mozilla.org/show_bug.cgi?id=149224 using the 07/10 trunk build.
build 2002071108; winxp
still choppy
btw: when visiting
http://www.go-mono.com/class-status-System.html
with the latest trunk build 2002071508 on win-xp pro I still crash.
----
//
// Watchdog Event Log File
//

LogType: Watchdog
Created: 2002-07-16 13:59:25
TimeZone: -60 - W. Europe Standard Time
WindowsVersion: XP
EventType: 0xEA - Thread Stuck in Device Driver

//
// The driver for the display device got stuck in an infinite loop. This
// usually indicates a problem with the device itself or with the device
// driver programming the hardware incorrectly. Please check with your
// display device vendor for any driver updates.
//

ShutdownCount: 317
Shutdown: 0
EventCount: 12
BreakCount: 12
BugcheckTriggered: 1
DebuggerNotPresent: 1
DriverName: nv4_disp
EventFlag: 1
DeviceClass: Display
DeviceDescription: NVIDIA GeForce2 Go (Dell Mobile)     
HardwareID: PCI\VEN_10DE&DEV_0112&SUBSYS_00E51028&REV_B2
Manufacturer: NVIDIA
DriverFixedFileInfo: FEEF04BD 00010000 0006000D 000A06E0 0006000D 000A06E0 
0000003F 00000008 00040004 00000003 00000004 00000000 00000000
DriverCompanyName: NVIDIA Corporation
DriverFileDescription: NVIDIA Compatible Windows 2000 Display driver, Version 
17.60 
DriverFileVersion: 6.13.10.1760
DriverInternalName: nv_disp.dll
DriverLegalCopyright: (c) NVIDIA Corporation. All rights reserved.
DriverOriginalFilename: nv_disp.dll
DriverProductName: NVIDIA Compatible Windows 2000 Display driver, Version 
17.60 
DriverProductVersion: 6.13.10.1760
---

This has been mentioned in bug 152992.
Is there a need to reopen or file a sperate bug?
I can get very slow scrolling if I am in 256 color mode, but not if I am in
millions of colors (every test case scrolls very smoothly).  But you have to
restart the app in 256 color mode to duplicate the problem.  Is this what
everyone is seeing?  If that is the case.. I do know what causes that, its the
blitting of 32 bit images to a 8 bit screen.. which requires a huge amount of
lookup which we have to fix.
Specifically responding for my situation, and bug 149224, I am using "32 bit"
video, with an Elsa Gloria Synergy Permedia video card with 8MB of vram. The
drivers are the most current available afaik (and I updated them within the
past two months).
Priority: -- → P3
I have coppy scrolling with all urls listed.
32bit color 1280x1024 winxp. latested build.
geforce 4(64mb)
Found a big problem.. we were painting the entire background everytime.. may
have been clipped.. but still cost alot.. to do that large of a blit.
it would be great if anyone would apply this patch and see if the performance
goes up on the test cases for you.. and/or if you see any problems.. its a very
very simple patch to one file.. and 3 lines are changed.  This could solve all
these background slowness problems.
dcone: Nice! This patch (in a current trunk build win32) completely fixes 
the problem I noted in bug 149224, attachment 86381 [details]. Good stuff.
1) anyone else have a chance to try out this patch?
2) dcone: is this a possibility for 1.1final?
*** Bug 124150 has been marked as a duplicate of this bug. ***
transferring keywords
Keywords: nsbeta1
Whiteboard: [adt2]
Blocks: 117601
Attached patch Cleaner patch. (obsolete) — Splinter Review
Attachment #92239 - Attachment is obsolete: true
Attached patch this is the correct patch. (obsolete) — Splinter Review
Attachment #92719 - Attachment is obsolete: true
Comment on attachment 92750 [details] [diff] [review]
this is the correct patch.

r=rods
Attachment #92750 - Flags: review+
Comment on attachment 92750 [details] [diff] [review]
this is the correct patch.

sr=kin@netscape.com
Attachment #92750 - Flags: superreview+
Attachment #92750 - Flags: approval+
Comment on attachment 92750 [details] [diff] [review]
this is the correct patch.

a=asa (on behalf of drivers) for checkin to 1.1
*** Bug 158694 has been marked as a duplicate of this bug. ***
checked into the trunk.  Fixed.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
this fix causes problems with the main toolbar & scrollbar graphics in modern.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached image screenshot
I backed out my changes.. I dont get those problems at all.  I will investigate
what is going on.
*** Bug 159954 has been marked as a duplicate of this bug. ***
Without respect to the downsides, this really improved scrolling for me on the
National Geographic page.  XP, matrox g450, 512mb, 2002072908 trunk.
I also saw the regression and reported it as bug 159985.  I suggest leaving
159985 open for today to reduce the number of dups and marking it as fixed tomorrow.
I'd been running with the earlier version of this fix (attachment 92239 [details] [diff] [review]) for 
several days, and had no problems. But, yeah, with attachment 92750 [details] [diff] [review], I also
see the drawing errors reported here and elsewhere.
*** Bug 159983 has been marked as a duplicate of this bug. ***
Is it just me or is there no functional difference on Windows between attachment
92239 [review] and attachment 92750 [details] [diff] [review]?
I'd like to thank Dean for pointing out that I am an idiot, and if I'd looked 
at the point in context, I would have seen that there is no functional 
difference between those two patches.

And, I also missed the effect that this patch had on Modern scrollbars (I 
rarely use Modern) and on <select> drop markers in html form controls. The 
patch does indeed fix the scrolling problem, but I really botched it when 
I missed those other issues. Sorry.
This patch fixes the scroll bar problem in the modern skins. Again I ran all my
test cases but this time under modern skin also.  Please test with this for a
while.	This patch takes the intersection of the tile rect and dirty rect like
we do for linux, but it also calculates the correct offset.
Attachment #92750 - Attachment is obsolete: true
Your indentation seems a little wacky in that last patch.
Attached patch Best patch. (obsolete) — Splinter Review
I found some small glitches with the last patch.. namely that the scroll bars
were missing there little horizontal lines.  This patch uses the Linux logic..
and seem to set everything correctly.  The last patches assumed a more
straighforward use of the offset.. apparently there can be some strange offsets
generated.  This patch has passed all my test so far.. I will keep testing. 
Please apply this and give any feedback.. I think this is important because if
fixes a ton of performance problems.
Attachment #93284 - Attachment is obsolete: true
Comment on attachment 93289 [details] [diff] [review]
Best patch.  

r=peterl
Attachment #93289 - Flags: review+
Comment on attachment 93289 [details] [diff] [review]
Best patch.  

sr=kin@netscape.com

You can move the xOffset and yOffset declaration into the |if| block if that's
the only place they are used.
Attachment #93289 - Flags: review+ → superreview+
This also seems to fix the slow painting and scrolling on the apges on
http://www.directv.com. I see r= and sr=, can we push this in, or are we still
waiting for something else here (other than approval)?
Er, s/apges/pages/
Comment on attachment 93289 [details] [diff] [review]
Best patch.  

a=asa (on behalf of drivers) for checkin to 1.1
Attachment #93289 - Flags: approval+
Please also add to the branch whenever possible since there are partners
affected. Thanks.
it seems for me that patch contains \r\n pairs ...and i met problem applying it
on  non-Win32 system
what was the problem.. it xplatform code.. actually.  Did the patch not apply,
or did once applied.. it did not compile?
I understand.. sounds like you need to set that option on patch in order to
work... I use the posix setting to get things working correctly.
bug 160103 came and went, seemingly corresponding to the first checkin / backout
of this fix. So this URL may be worth testing:
http://www.w3.org/TR/REC-html40/interact/forms.html
Comment on attachment 93289 [details] [diff] [review]
Best patch.  

marking r=peterl

can't this be checked in now?
Attachment #93289 - Flags: review+
checked into the trunk.  Fixed.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
ver fixed on build id 2002080108 on win xp
Build 2002080119, Win2K, Matrox G400

Just noticed a new redrawing problem. It think it is caused by the path for this
bug.

Reproduce:
1. Open http://www.tweakers.net and maximize your window
2. Open a new window in front of the browser and move it like a maniac over the
Mozilla window (must have show while dragging on). You will see the black
background on the right side sometimes turn light gray.

Can anyone confirm this and should a new bug be opened or not? After all, the
patch itself may be correct, this can be another bug in Moz.
Backed out changes.. seems there are some inconsitent ways we use the
backgrounds.. and some assumtions we make.  I have to study this some more.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Test case to check against for the next patch. 
http://www.angelfire.com/space/jlariviere/
Just an additional note about the test webpage: Under the Select Styles... you
can click on a link to change the page style.   Also, (I think it's related to
your changes...) if you change the style enough times it causes mozilla to crash
everytime (I'm clicking a link every 2-3 seconds).  I'll double check tomorrow
with the build with the changes backed out that it does not still happen.
This screenshot is 080208 on Windows 2000.  I have been using the build all day
and I've only seen the problem once in Navigator and once in Mail.  I don't
know how to reproduce this problem.  This isn't horrible corruption like with
the build from several days ago; it's just a background color showing through
where the background image should appear.
http://www.thekompany.com/home/ that I tested with.  I found the problem...
there was an offset variable used in nsImageWin::DrawTile for the alpha (depth
of 8 bits) that was not right.  The offset was always 0 when
nsCSSRendering::PaintBackgroundWithSC called this routine.  When I changed it to
the new way the offset passed in would not always be 0 and this offset was used
incorrectly for alpha.  I fixed it.  I will post the patch.
Passes all my current tests.  These test include the past and also the more
recent tests that caused the problems.
Attachment #93289 - Attachment is obsolete: true
Attachment #94076 - Attachment is obsolete: true
Comment on attachment 94332 [details] [diff] [review]
Slightly cleaned up version of last patch.

r=rods
Attachment #94332 - Flags: review+
*** Bug 133261 has been marked as a duplicate of this bug. ***
Patch seems to work fine. Solves the National Geograpic site and seems to solve
some DHTML performance bugs (at least bug 157401), but the saucagetools and
splendorofflorance.com (see comment #21) are still somewhat slow here (Cel 466,
Matrox G400).

Will the patch make it into 1.1?
nsbeta1+.
Keywords: nsbeta1nsbeta1+
Target Milestone: --- → mozilla1.2alpha
A bug that I tested with the newest patch.. putting it here for documentation
about the pages that are tested with the patches.
http://bugzilla.mozilla.org/show_bug.cgi?id=160664
Comment on attachment 94332 [details] [diff] [review]
Slightly cleaned up version of last patch.

With your changes, it looks like you can replace all references to
ScaledTileHeight_Offset and ScaledTileWidth_Offset with ScaledTileHeight and
ScaledTileWidth.

sr=kin@netscape.com with that change.
Attachment #94332 - Flags: superreview+
*** Bug 162380 has been marked as a duplicate of this bug. ***
Attached patch New Patch.Splinter Review
I found a new problem.. a PNG did not scroll correctly, the offsets were all
messed up.  It was because of the reverse order of the bitmap and how the
offsets were passed in.  I reversed how I went through the bitmap to be in sync
with the tiles and offsets passed in. IT Fixed that bug and I tested with all
my test cases and the URLS put in this bug report.  All check out great.
Attachment #94332 - Attachment is obsolete: true
Comment on attachment 95279 [details] [diff] [review]
New Patch.

sr=kin@netscape.com
Attachment #95279 - Flags: superreview+
sorry for the spam

dcone, when can we expect a check-in? I have not downloaded a nightly build
since the very first check-in and its killing me :)
Fixed.  Scrolling should be 100% faster.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
I was hoping that the fix for this would fix the scrolling bug at 
http://www.meyerweb.com/eric/css/edge/ , but it doesn't.

Notice the Astronaut in the background.  Try scrolling and watch the astronaut 
get chopped up in to little pieces.  Is this something that should have been 
addressed by this bug, or is it another issue?

Note that to really reproduce this, you should make the horizontal size of the 
browser pretty small and then scroll up and down.  You will notice that either 
the part of the astronat that goes offscreen disapears or is stretched out into 
little pieces.  Resizing the browser window snaps the image back to its 
original form.

Jake
http://www.exactaudiocopy.de 
is still choppy on scrolling and mouse-over of left menu-items are not very 
responsive (really very slow).
Using trunk build 2002081908 on win-xp pro,1.1ghz,512ram,GeForce2 Go (32MB).

in answer to comment #95 :

scrolling is smooth (using mouse wheel / cursor key), with trunk build
2002081904 - WinXP

Maybe my Athlon XP1800+ / 512 Mo / GF4 Mx is way to fast ? ;-)
Try draging the scrollbar up & down (quite fast).
What about the very slow responding mouseovers on the menu-items on the left 
side?
In answer to comment #97 :

no problem at all, there seems to be blocked in a frame on the left side, so no
refresh problem at all !
Build 2002081908 on win95 (I know, don't tell me, it's not mine)

http://www.exactaudiocopy.de is here also very slow. It is caused by the 3 huge
background images in the <td> tags. The background image is 1200x1400. Removing
the image makes it scroll fast. Even scrolling the image itself (
http://www.exactaudiocopy.de/cell_bck.gif ) is slow here.

Suggesting to reopen this bug.
Another data point on the site http://www.exactaudiocopy.de: scrolling using
keyboard, mouse and scrollbar all seem smooth and fast for me (though the
throbber is continuous).  2002081904 on XP, Athlon 1.2ghz, 512mb, Matrox g450.

So far, this seems like wonderful work, dcone!
I checked out http://www.exactaudiocopy.de/ on my PIII 450 with 384meg RAM and 
a 3dfx Voodoo3 with 16meg RAM.

Scrolling is not perfectly smooth, but completely acceptable.  Totally usable.  
However, the mouseovers on the left side unacceptably slow.  I checked on IE5.5 
on the same machine and scrolling is smooth (slightly more so than Mozilla) and 
the mouseovers are *way* faster than Mozilla.

This patch definitely provided an improvement, but there is still some more 
work to be done.  Plus, don't forget about comment 94 where there is still some 
foo with the background image being chopped up.

Jake
A few things I want to bring out.
1.)  As far as the urls I tested and this bug addresses, I think I have fixed a
major scrolling bug.  Now if you have scrolling or hoovering issues I think you
need to show how that relates to this bug (a regression, minimal speed increase,
etc) so this bug will stay on track.  If you can not show a relationship then a
new bug needs to be opened and some research into what may cause this problem.  
My tests show at least 3 to 4 times speed increase with the URL's listed in this
bug.  If you have a site that is not fast at scrolling.. please indicate how
that relates to this bug and if the fix here had any impact.  

2.)  If you open a bug about scrolling.. a comment like.. not very fast.. is not
good enough.  Please try to quantify the speed problem.

3.)  Any regressions need to be addressed in this bug.. thats very important. 
But if you have a bug that is not a regression and were hoping this may fix it
but did not.. open a new bug.  

4.)  Other issues.. like a hoover.. please open a new bug or find a bug that is
already open and list the issue there.  

5.)  There are probably a bunch of issues that come close to this bug.. but if
your comment is.. this url does not scroll fast.. it would help alot if the
comment was more like .. this fix did not improve the speed of this url, more
along the lines of how your comment relates to the fix.  


I think comments added should relate to this bug and the fix I put in.  If you
read the bug and the patch you will see that a huge issue was addressed.. and I
appreciate all the help.  I just want the bug to stay on track and comments to
relate directly to this fix and the urls that were used to find, test and
re-test this (the regressions caused by the fix).
Though the performance is now much better, I see a terrible regression on
http://www.swva.net/  Mousing over the links creates a floating box which causes
the background to not repaint properly.  Also, moving another window over the
background causes the same effect-- incorrect/no repainting.
comment #94 is something else.  This problem existed in 1.1a.  If not already
filed, this should be made another bug, though it looks a lot like the PNG
compositing problems that were fixed several months ago.
don't now whether this is of any value but:

I can reproduce the original bug (slow scrolling)on the site

www.sysinternals.com

(using: Mozilla 1.0.0
Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.0.0) Gecko/20020530)

reason: (as already determined) a large background gif image with the size 
of 1600 x 1 pixel.

now, if I change the background image to 128 x 1 pixel or below, the scrolling
is fast and smooth.

I'm not a software programmer, but doesn't *128* ring a bell?  
tloehnert@web.de, you need to download the latest nightly build from
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/ to test this bug. AFAIK, this
is not patched for Mozilla 1.0 yet. When you download a nightly build, try
testing the site then and you will notice that it is fixed.
Reopened for the regressions found.  I found a png problem and also the problem
found in comment 103.  I have a patch to be posted shortly.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Patch fixes the PNG update problem ( offsets were not calculated correclty for
updates) and progressive doubling problem ( the buffer size was to small). 
Also did some basic cleanup of those two routines.
Comment on attachment 96676 [details] [diff] [review]
Patch to fix update problems.

r=rods
Attachment #96676 - Flags: review+
Comment on attachment 96676 [details] [diff] [review]
Patch to fix update problems.

sr=kin@netscape.com
Attachment #96676 - Flags: superreview+
fixed problems with new patch.. all checked in.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
*** Bug 166129 has been marked as a duplicate of this bug. ***
Verifying this old problem is not occuring in the (2003-06-11-08) Win32 trunk or
(2003-06-11-05) win32 branch. Tested under Win XP.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: