Closed Bug 141786 Opened 22 years ago Closed 22 years ago

Long page with many tables scrolls choppily

Categories

(Core Graveyard :: GFX, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: susiew, Assigned: dcone)

References

()

Details

(Keywords: perf, topembed+, Whiteboard: [adt2 RTM] [ETA 06/18])

Attachments

(1 file, 2 obsolete files)

I'm sure there's a way to evangelize this but hopefully there is something that can be optimized to smooth scrolling on a page like this. To replicate: Scroll down http://www.seattlesbest.com/site/locations/ Win2K 2002043006
Susie, is this only choppy on Win2k, or also on Win9x?
Does this have images, or background tiles. There was a checkin on the trunk yesterday that fixed this for images.
Scrolls smoothly using 2002050706 build on WinXP, 750Mhz Athlon, ATI 3D RAGE IIC AGP graphics card
Reassigning to Don.
Assignee: kmcclusk → dcone
There is a certain optimization to using the progressive doubling. The cost of creating the offscreen buffers etc can slow down just blitting.. so I tuned this a little... and it fixes this bug..and does not regress my other test cases.
Scrolled smoothly on Win98 with embedded Mozilla 1.0. (still choppy for me on Win2K with rv:1.0rc2 Gecko/20020512)
it should still be slow for you because I did not check anything in to the branch or the trunk.
I know...I was just confirming I hadn't had a caffeine induced impatient scrolling episode.
Attached patch better patch.. (obsolete) (deleted) — Splinter Review
Attachment #85264 - Attachment is obsolete: true
*** Bug 147799 has been marked as a duplicate of this bug. ***
Keywords: patch, perf
*** Bug 148036 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0.1
Comment on attachment 85437 [details] [diff] [review] better patch.. Please add a comment which explains why the magic value of 32 is being used. Example: for tiled backgrounds which require less than 32 blits it is faster to blit directly to the screen instead of blitting to an offscreen and doing progressive doubling. r=kmcclusk@netscape.com.
Attachment #85437 - Flags: review+
cvs diff -u, in the future, please! Does the comment above this line need to change? Specifically, the part that says: `and the tile is at least 8 times smaller than the area to update'?
Attachment #85437 - Attachment is obsolete: true
Attachment #85649 - Flags: superreview+
Comment on attachment 85649 [details] [diff] [review] forgot the -u.. and put in a comment. sr=waterson
*** Bug 149224 has been marked as a duplicate of this bug. ***
Comment on attachment 85649 [details] [diff] [review] forgot the -u.. and put in a comment. please land this on the 1.0.1 branch. once there remove the "mozilla1.0.1+" keyword, and add the "fixed1.0.1" we're willing to go w/ no trunk baking first on this minor (apparently :-) ) tuning.
Attachment #85649 - Flags: approval+
Blocks: 46942
Has this been checked into trunk? I see a vast scrolling perf difference from 1.0 release, when using 2002060908, Win2K on the above site. No exactly IE parity but very close to it.
fixed. Checked into the trunk.
fixed.. forgot to mark
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
adt1.0.1+ (on ADT's behalf) for checkin to the 1.0 branch. pls check this in asap, then add the "fixed1.0.1" keyword.
Keywords: adt1.0.1+, nsbeta1+
Whiteboard: [adt2 RTM] [ETA 06/18]
It scrolls like a dream! (6/20 trunk) Thanks!
Keywords: topembed+
well..I can not check this into the branch.. seems the branch is missing many pieces to this puzzle (lots of patches has changed this code) and its not up to date enough to take this simple patch.
Removing adt1.0.1+, as a result of Comment #23 From dcone@netscape.com.
Keywords: adt1.0.1+
Removing mozilla1.0.1+; see new bug assigned to dcone for pulling this and the related earlier tiling patches into the branch for 1.0.2
Keywords: mozilla1.0.1+
This bug should be reopened correct? It is critical to get this issue fixed and on the branch for embedding please.
susiew: I believe that the bug that rjesup was referring ot is bug 162747: "Update branch tiling drawing/doubling code to match trunk". Per comment 23, dcone notes that he can't directly apply the trunk changes on the branch.
Ok. Using 2002081308 trunk on this site http://www.mr4000.com/, scrolling is out of control. I can't even use the page at all.
Comment #28 problem also occurs in Gecko/20020821 commercial branch build, I guess as expected. These sites are still scroll poorly in this build but I'll copy these comments to the bug 162747 http://www.seattlesbest.com/site/locations/ http://www.sfgate.com/traffic/ (which I thought was due to bug 153217) FYI the other site in bug 153217 scrolls fine.
this looks fine using a recent (2003.06.10.05-1.4) build on win2k. marking verified.
Status: RESOLVED → VERIFIED
Looking at http://jobs.volt.com/JobSearch/Jobs.cfm with 2003090204 trunk seems to indicate that this bug is not fixed. It is so bad on that page that even moving the mouse around the page consumes major CPU power. Removing the background GIF from the pages fixes the behavior.
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: