Closed
Bug 170928
Opened 22 years ago
Closed 22 years ago
Mozilla becomes choppy after scrolling an IFrame within a frameset
Categories
(Core :: Layout: Images, Video, and HTML Frames, defect, P1)
Core
Layout: Images, Video, and HTML Frames
Tracking
()
VERIFIED
FIXED
mozilla1.2beta
People
(Reporter: bugzilla, Assigned: kmcclusk)
References
()
Details
(Keywords: perf, regression, Whiteboard: [ADT1])
Attachments
(2 files, 1 obsolete file)
1.91 KB,
application/x-zip-compressed
|
Details | |
1.02 KB,
patch
|
rods
:
review+
kinmoz
:
superreview+
|
Details | Diff | Splinter Review |
(Under Win 98, Dell PII-350, 64MB Ram ATI Rage Pro Graphics) When I scroll an iframe within a web page I get really choppy scrolling, this is a new problem since they scroll fine in Mozilla 1.1 and IE. The first build to exhibit this problem is : Mozilla 1.2b Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20020920 Nightly Build Folder: 2002-09-20-04 Can't work out which check-in would be most likely to have caused this problem and haven't seen many other people complain about this yet.. http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=09%2F18%2F2002&maxdate=09%2F20%2F2002+09%3A30&cvsroot=%2Fcvsroot
Comment 1•22 years ago
|
||
You have any url or testcase to show this?
Reporter | ||
Comment 2•22 years ago
|
||
As it turns out, while trying to come up with a testcase I've found that the scrolling performance of an iframe if fine, it's when that iframe is within another frameset that things get sticky. Attachment coming up..
Summary: Choppy IFrame Scrolling → Choppy IFrame Scrolling (Within frameset)
Reporter | ||
Comment 3•22 years ago
|
||
Extract these files and open the file index.html in mozilla, try scrolling the iframe.. pretty bad on my machine..
Comment 4•22 years ago
|
||
Seing this also on Windows XP, build 20020924. Scrolling was smooth a while ago, now its really choppy.
Keywords: regression
Comment 5•22 years ago
|
||
->Frames
Assignee: attinasi → jkeiser
Component: Layout → HTMLFrames
QA Contact: petersen → amar
Reporter | ||
Comment 6•22 years ago
|
||
I'm not sure if this should be considered a Frames only bug (although it's certainly most easily spotted using frames)- there's a general increase in sluggish-ness in the whole UI compared to 1.1 (which I would say started with nightly 2002-09-20-04)- any thoughts?
Updated•22 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla1.2
OS: Windows 98 → All
Hardware: PC → All
Reporter | ||
Comment 7•22 years ago
|
||
Serously folks, things are really going pear shaped here, I'm surprised more people aren't having problems- on the nightly phoenix build I'm getting ~0.5 second delays between any user input and a response by the browser (even on pages without frames) - can anyone point me too another bug? Menus, links, scrolling everything has gone to pot speed wise, is no-one else having this problem? could it be graphics card specific?
Comment 8•22 years ago
|
||
Changing summary since this not only affects the actual scrolling but slows down the whole browser.
Summary: Choppy IFrame Scrolling (Within frameset) → Mozilla becomes choppy after scrolling an IFrame within a frameset
Comment 9•22 years ago
|
||
*** Bug 171580 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 10•22 years ago
|
||
WFM: Using 2002092904 trunk Mozilla build on WinXP on 750Mhz AMD. The example scrolls smoothly. The url in Bug 171580 also scrolls smoothly.
Comment 11•22 years ago
|
||
WFM with trunk build : 2002-09-20-08-trunk on WIN2K. Marking wfm.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Comment 12•22 years ago
|
||
REOPEN: I see this with Win 98, Build: ID 2002-09-28-08, but not with Build 2002-09-21, also with an ATI Rage Graphics Card. Mozilla will become unusable for me when visiting such a site.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Reporter | ||
Comment 13•22 years ago
|
||
This may be a Win 98/Ati graphics only problem (so quite common then..). Any chance of someone looking at the checkins for the first build (nightly 2002-09-20-04) that went wrong to see if anything obvious changed?
Comment 14•22 years ago
|
||
This is not an ATI Graphics problem, I see this and I don't have a ATI-card. Has anyone seen this on Mac?
Comment 15•22 years ago
|
||
I see this too. It should be noted that it isn't as much of a problem with the scrollwheel, but it a serious problem with the manual controls. Win 98 - Nvidia Video Card 20020930
Comment 16•22 years ago
|
||
The best way to find out about this is to simply scroll anything on this page: resource:///res/samples/test9.html I have a NVIDIA graphic card with the latest drivers.
Reporter | ||
Comment 17•22 years ago
|
||
Hey, this is interesting.. If I'm using phoenix 0.2 (and I would expect in mozilla as well), things are ok, scrolling is a little choppy on big pages like slashdot's front page. If I then open a tab with my testcase frameset the performance of the *WHOLE BROWSER* degrades, menus, links, scrolling, typing -everything. If I close that tab again then things return more or less back to normal. is each further frame sucking up processor time? Is their a change to the way mozilla is listening for and processing event for each consecutive frame within the frameset, resulting in slower performance with each set of frames added to the frameset? Performance does not seem to degrade much with each new document tab, just when more frames are present within a given document. Note: there is no point marking WFM if your testing on a fast machine with Win2k/XP - this may be Win98 only and is certainly more apparent on slow machines (PII-350) - testing with a 750Mhz AMD and WinXP? come on guys... the faster you can go the less you'll see a problem.. Randomly CC'ing folk who made checkin's to the first affected build.
Comment 18•22 years ago
|
||
nothing i did.
Comment 19•22 years ago
|
||
Also, one other thing, scrolling anything on Mozillas Frame example (#9) makes CPU Usage go up to 100%. Testing on 2000 and XP.
Assignee | ||
Comment 20•22 years ago
|
||
" testing with a 750Mhz AMD and WinXP? come on guys..." Christopher: It is perfectly valid to put WFM: with any given configuration in a bug for informational purposes. You'll notice, I did *not* close out the bug after I put in that notation.
Reporter | ||
Comment 21•22 years ago
|
||
Sorry Kevin, I guess I felt that the chorus of WFM coming from netscape perhaps sounded dismissive of the bug. I realise that's not the case.
Comment 22•22 years ago
|
||
Scrolling the iframe test is choppy for me under Windows ME using the 2002-10-02-08 trunk build. Tested with true color video(32 -bit) setting at 1152 x 864 resolution.
Assignee | ||
Comment 23•22 years ago
|
||
According to Sebastian's comment #12 the regression happened between 2002-09-21 and 2002-09-28-08. But Chrisopher indicates that the regression appears on a 2002-09-20-04 build? Sebastian are you sure about it working correctly on the 2002-9-21 date? Can others seeing this problem confirm that the regression is not present on a 2002-9-19 build, but it is present on a 2002-09-20 build to confirm the timeframe for the regression?
Comment 24•22 years ago
|
||
Kevin: I'm not sure this was build 2002-09-21 (this was maybe build 09-20). I cant make regression test, because mozilla.org has a 30GB HD (this is ridiculous), and so mozilla.org is offering me only build since (including) build 2002-09-24. (No I dont have resources to build from CVS)
Reporter | ||
Comment 25•22 years ago
|
||
I've re-tested the builds I have and for me the issue does make it's first appearance in the 2002092004 build and continues to occur in 2002092104 (don't have any later builds for that day)- the files in the first affected build have the creation time of 2002-09-20 06:11 if thats any help.
Assignee | ||
Comment 26•22 years ago
|
||
Taking bug for further investigation.
Assignee: jkeiser → kmcclusk
Status: REOPENED → NEW
Assignee | ||
Comment 27•22 years ago
|
||
Assignee | ||
Comment 28•22 years ago
|
||
I was able to reproduce the problem by increasing the number of iframes in Christopher's original test case to 6 iframes. The patch I attached fixes the problem by correcting an error in the enumeration of child windows which is performed to dispatch paint events after a mouse or key event. The current code incorrectly assumes that ::EnumChildWindows will process only the direct descendants (its children). Instead ::EnumChildWindows processes all of the descendants. This causes a performance problem because nsWindow::DispatchStarvedPaints(HWND aWnd, LPARAM aMsg) was calling ::EnumChildWindows which meant that the child windows were being enumerated way too much.
Assignee | ||
Comment 29•22 years ago
|
||
Attachment #101779 -
Attachment is obsolete: true
Assignee | ||
Comment 30•22 years ago
|
||
nsbeta1+, [ADT1]
Comment 31•22 years ago
|
||
Comment on attachment 101782 [details] [diff] [review] same as last patch with corrected comments. r=rods
Attachment #101782 -
Flags: review+
Comment 32•22 years ago
|
||
Comment on attachment 101782 [details] [diff] [review] same as last patch with corrected comments. sr=kin@netscape.com
Attachment #101782 -
Flags: superreview+
Assignee | ||
Comment 33•22 years ago
|
||
Fix checked into the trunk.
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 34•22 years ago
|
||
That done the trick, fantastic work! Thanks for that.
Updated•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•