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)

defect

Tracking

()

VERIFIED FIXED
mozilla1.2beta

People

(Reporter: bugzilla, Assigned: kmcclusk)

References

()

Details

(Keywords: perf, regression, Whiteboard: [ADT1])

Attachments

(2 files, 1 obsolete file)

(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)
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.
->Frames
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
Keywords: mozilla1.2
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?
Keywords: perf
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. ***
Blocks: 100951
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
Closed: 22 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
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. 
Attachment #101779 - Attachment is obsolete: true
nsbeta1+, [ADT1]
Keywords: nsbeta1+
Priority: -- → P1
Whiteboard: [ADT1]
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.

sr=kin@netscape.com
Attachment #101782 - Flags: superreview+
Fix checked into the trunk.
Status: NEW → RESOLVED
Closed: 22 years ago22 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
Product: Core → Core Graveyard
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.

Attachment

General

Created:
Updated:
Size: