(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
You have any url or testcase to show this?
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)
Created attachment 100722 [details] zip containing an example frameset and iframe Extract these files and open the file index.html in mozilla, try scrolling the iframe.. pretty bad on my machine..
Seing this also on Windows XP, build 20020924. Scrolling was smooth a while ago, now its really choppy.
Assignee: attinasi → jkeiser
Component: Layout → HTMLFrames
QA Contact: petersen → amar
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Hardware: PC → All
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?
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
*** Bug 171580 has been marked as a duplicate of this bug. ***
WFM: Using 2002092904 trunk Mozilla build on WinXP on 750Mhz AMD. The example scrolls smoothly. The url in Bug 171580 also scrolls smoothly.
WFM with trunk build : 2002-09-20-08-trunk on WIN2K. Marking wfm.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
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 → ---
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?
This is not an ATI Graphics problem, I see this and I don't have a ATI-card. Has anyone seen this on Mac?
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
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.
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.
nothing i did.
Also, one other thing, scrolling anything on Mozillas Frame example (#9) makes CPU Usage go up to 100%. Testing on 2000 and XP.
" 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.
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.
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.
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?
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)
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.
Taking bug for further investigation.
Assignee: jkeiser → kmcclusk
Status: REOPENED → NEW
Created attachment 101779 [details] [diff] [review] Fix enumeration of childwindows when dispatching pending paint events
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.
Created attachment 101782 [details] [diff] [review] same as last patch with corrected comments.
Attachment #101779 - Attachment is obsolete: true
Priority: -- → P1
Target Milestone: --- → mozilla1.2beta
Comment on attachment 101782 [details] [diff] [review] same as last patch with corrected comments. r=rods
Attachment #101782 - Flags: review+
Comment on attachment 101782 [details] [diff] [review] same as last patch with corrected comments. firstname.lastname@example.org
Attachment #101782 - Flags: superreview+
Fix checked into the trunk.
Status: NEW → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → FIXED
That done the trick, fantastic work! Thanks for that.
verified on branch 2003-06-03-05-1.4 winXP
Status: RESOLVED → VERIFIED
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.