124178 - Hang on DHTML [reflow/painting]

Status: RESOLVED FIXED

(Core Graveyard :: GFX, defect, P2)

Description

[Markus Hübner]

a new window opens and a few secons later mozilla hangs.
Doesn't hang in mozilla0.9.7
using 2002020603 on win-xp

Comment 1

[David Pedowitz]

Checked on build 2001122106 (0.9.7) and as described it didn't hang but that 
was a horrible experience, worst DHTML perf I've ever seen...

The page animates text along a sin curve by creating an object for each 
character and animating one after the other after the other and so on...  I 
just don't think Moz can handle it :(

Confirmed on win2k 0.9.8 build 2002020406

This is the actual page: http://audi.vw-audi.es/ttroadster/home.html

Comment 2

[Matthias Versen [:Matti]]

-> Dom0

Comment 3

[Boris Zbarsky [:bzbarsky]]

compositor based on profile.  We're spending lots of time painting...

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Profile data from jprof

Comment 5

[Markus Hübner]

This is one of the worst DHTML examples ever seen for Mozilla.
Though having 1.1ghz, 327RAM this pages makes my system really very tough 
responding.

Comment 6

[Axel Hecht]

This is more a evang issue. I'm tempted to add a 4xp keyword and 'mildly hang'.
Menus on NS4 have several seconds delay on this page.
Looking at all the constructs in the source that you get from glancing at
the first few loaded files, I recommend moving this out to evang.

Comment 7

[basic]

I think we should at least keep this as a real world benchmark of sorts, if
other browsers can do this faster, I don't see why moz can't.

Comment 8

[Markus Hübner]

All DHTML works perfectly in ns4.78 on winxp
Here ns4.78 responds quickly and the sin-line animated elements are flying 
like the wind. Eager to know what NS4.X is doing differently than Mozilla.

Comment 9

[Axel Hecht]

I just saw this one:
http://mozilla-evangelism.bclary.com/
What needs to be done today? has a whole section about DynAPI (which this site
is using). Adding dep to they DynAPI tracking bug.

Comment 10

[Bob Clary [:bc] (inactive)]

Actually it appears this site is using DynAPI2 from sourceforge. The version on
bclary.com is an updated version of DynAPI1 that supports Gecko. The two apis
are very distinct.

Comment 11

[Daniel Bratell]

I've looked a little on what happens and as far as I can tell, we're just
reflowing forever. Apparently the reflows starve all painting so nothing is ever
displayed.

The center in the reflow chain seems to be nsAbsoluteContainingBlock::Reflow. 
nsBlockFrame::Reflow calls nsAbsoluteContainingBlock::Reflow which calls
nsBlockFrame::Reflow. Three quarters of the time if spent in
nsAbsoluteContainingBlock::Reflow and its descendants. 

If that's alright (i don't know) further down
nsAbsoluteContainingBlock::ReflowAbsoluteFrame and
nsBlockFrame::ReflowDirtyLines (through PlaceFrameView) calls
nsContainerFrame::SyncFrameViewAfterReflow.

nsContainerFrame::SyncFrameViewAfterReflow is 64% of the total time. It does a
CreateRegion which is slow (bug 124683). It also calls
nsViewManager::nsResizeView which ends up doing
nsViewManager::UpdateAllCoveringWidgets (bug 124685). Futhermore 7% is spent in
nsRegionWin::SetTo (bug 124686).

As for the nsAbsoluteContainingBlock::Reflow it might be bug 75121, but I'm not
sure. 

(This bug looks a lot like bug 97287, the difference being that on this page the
DHTML JavaScript never stops so it looks like a hang)

Comment 12

[Markus Hübner]

Is 122976 a dupe of this one?

Comment 13

[Kevin McCluskey (gone)]

Bulk moving Mozilla1.1 bugs to future-P2. I will pull from this list when
scheduling post Mozilla1.0 work.

Comment 14

[Ronald van Kuijk]

This should also have a dependency on bug 129115. I tried the url with the
experimental build of bug 129115 and it is a *MAJOR* improvement compared to the
trunk build. 

I'd like to add the dependency, but have no rights.

Comment 15

[José Jeria]

Still hangs on Windows 2000, but on MAC OS 9 everything is OK.

Comment 16

[Kevin McCluskey (gone)]

WFM: Doesn't hang using 2002081008 build on WinXP.

->dcone

Comment 17

[José Jeria]

WFM too now, Windows 2000, build 20020812

Comment 18

[Markus Hübner]

will do some extensive testing and report results soon.

Comment 19

[Markus Hübner]

No hang anymore - trunk of 2002092404 - winxp pro :)
think that was due to 157144 / 164931.