Max Alekseyev Reporter
	Description • 21 years ago

Linux build 2004032608

To reproduce:
1. Open provided URL
2. (Optionally) try to scroll the page while it's being loaded
3. After a while Mozilla becomes inoperable (does not redraw its window etc.)

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 21 years ago

The page basically looks like this:

<table><tr><td>

lots (170,000 or so) of lines like "xxx <br>" (where "xxx" is just text).

</td></tr></table>

We seem to be spending all our time in reflow; in particular, about half the
time is spent in WrappedLinesAreDirty() (which looks to me like it should make
reflow O(N^3) in this case, since all the lines are wrapped and the only dirty
ones should be at the very end, so each call to it is O(N), there are O(N) calls
per ReflowDirtyLines call, and there are O(N) ReflowDirtyLines calls).  I tried
making WrappedLinesAreDirty actually dirty all the lines from aLine up to the
dirty continuation, in the hope that this would make the number of calls to it
O(1), but that doesn't seem to help too much (since now the whole thing is
O(N^2) instead of O(N^3)).

The basic issue, of course, is that if any continuation of a line is dirty the
line itself gets marked dirty when we're computing the maxwidth.  And that
means, in this particular case, that each append reflows all the content
previously received, making the whole load O(N^2) or worse.

Other than WrappedLinesAreDirty(), the time is spent under
nsBlockFrame::ReflowInlineFrame.

	Boris Zbarsky [:bzbarsky]
	Comment 2 • 21 years ago

Of course lines ending in <br> should probably not be marked as wrapped....

	Boris Zbarsky [:bzbarsky]
	Comment 3 • 21 years ago

The _real_ problem are all the unescaped '<' in this page.  As a result, we _do_
have a bunch of nested inlines, which are in fact incomplete (hence the lines
are marked as wrapped).  Even if I put the SetLineWrapped(PR_TRUE) calls inside
|if (!aLineLayout.GetLineEndsInBR())| (which I think is the right thing to do),
we still have issues with the page (this time in nsFrameList::AppendFrames,
probably called as we push frames across the inline continuations).  Bug 233463
could help there, but I'm sure we'd run into another problem.  The real issue is
the very deep all-inline DOM tree, and we have bugs on that, as I recall.

I'll attach the changes I've made while debugging this, in case we ever feel
like checking them in.

	Ryan VanderMeulen [:RyanVM]
	Comment 5 • 17 years ago

Still a pretty nasty CPU and memory usage spike on the current trunk. However, the browser *is* usable while the page is loading.