170928 - Mozilla becomes choppy after scrolling an IFrame within a frameset

Status: VERIFIED FIXED

Description

[Christopher Cook]

(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

[José Jeria]

You have any url or testcase to show this?

Comment 2

[Christopher Cook]

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..

Comment 3

[Christopher Cook]

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..

Comment 4

[José Jeria]

Seing this also on Windows XP, build 20020924. Scrolling was smooth a while ago,
now its really choppy.

Comment 5

[Christopher Hoess (gone)]

->Frames

Comment 6

[Christopher Cook]

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?

Comment 7

[Christopher Cook]

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

[Markus Långström]

Changing summary since this not only affects the actual scrolling but slows down
the whole browser.

Comment 9

[Markus Långström]

*** Bug 171580 has been marked as a duplicate of this bug. ***

Comment 10

[Kevin McCluskey (gone)]

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

[Amarendra Hanumanula]

WFM with trunk build : 2002-09-20-08-trunk on WIN2K. Marking wfm.

Comment 12

[Sebastian Biallas]

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.

Comment 13

[Christopher Cook]

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

[Markus Långström]

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

[Mike Young]

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

[José Jeria]

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.

Comment 17

[Christopher Cook]

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

[Mike Pinkerton (not reading bugmail)]

nothing i did.

Comment 19

[José Jeria]

Also, one other thing,
scrolling anything on Mozillas Frame example (#9) makes CPU Usage go up to 100%.

Testing on 2000 and XP.

Comment 20

[Kevin McCluskey (gone)]

" 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.

Comment 21

[Christopher Cook]

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

[Chris Petersen]

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. 

Comment 23

[Kevin McCluskey (gone)]

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

[Sebastian Biallas]

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)

Comment 25

[Christopher Cook]

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.

Comment 26

[Kevin McCluskey (gone)]

Taking bug for further investigation. 

Comment 27

[Kevin McCluskey (gone)]

Created attachment 101779 [details] [diff] [review]
Fix enumeration of childwindows when dispatching pending paint events

Comment 28

[Kevin McCluskey (gone)]

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. 

Comment 29

[Kevin McCluskey (gone)]

Created attachment 101782 [details] [diff] [review]
same as last patch with corrected comments.

Comment 30

[Kevin McCluskey (gone)]

nsbeta1+, [ADT1]

Comment 31

[rods (gone)]

Comment on attachment 101782 [details] [diff] [review]
same as last patch with corrected comments.

r=rods

Comment 32

[kinmoz]

Comment on attachment 101782 [details] [diff] [review]
same as last patch with corrected comments.

sr=[e-mail]

Comment 33

[Kevin McCluskey (gone)]

Fix checked into the trunk.

Comment 34

[Christopher Cook]

That done the trick, fantastic work! Thanks for that.

Comment 35

[Madhur Bhatia]

verified on branch 2003-06-03-05-1.4 winXP