22810 - Incremental Reflows of "special" frames are slow (WipeContainingBlock)

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[rothwell]

Take a look at http://216.27.61.27 with M12 (for linux in my case). It renders
very slowly, and incorrectly. Some of the links don't show up (enter a zip code
to display the movie listings). And some of the fonts are incorrect (but
correct in other browsers). With Navigator 4.7 and IE 5.0, it renders quickly.
Also notice the jumping input boxes in the "login" widget. On slower machines
(i.e., pentium @ 225MHz), this is awful. The other difference is the black bars
below the left-hand boxes -- they are smaller or absent in other browsers.
Also, I couldn't actually use M12 to submit this bug report because I could not
log in. Internet Explorer did.

Comment 1

[troy]

Vidur, mostly the page loads reasonably fast for me; however, occasionally it
loads slowly and you can see the table thrash about as columns are added.

I dumped out some state that shows the calls to the frame construction code, and
in the slow case we get an extra ContentRemoved(), a couple of
ContentInserted(), and a few ContentAppended() calls.

The ContentRemoved() and ContentInserted() calls are the scary ones.
Re-assigning so you can better diagnose why. Here is my debug output:

Going to create the event queue
WEBSHELL+ = 1
plugins at: E:\mozilla\dist\WIN32_D.OBJ\bin\plugins
FCC: ContentInserted() called!
Note: styleverifytree is disabled
Note: frameverifytree is disabled
Note: verifyreflow is disabled
FCC: ContentAppended() called!
FCC: ContentAppended() called!
WEBSHELL+ = 2
FCC: ContentInserted() called!
FCC: ContentAppended() called!
FCC: ContentAppended() called!
FCC: ContentAppended() called!
FCC: ContentAppended() called!
FCC: ContentAppended() called!
FCC: ContentAppended() called!
FCC: ContentRemoved() called!
WEBSHELL- = 1
FCC: ContentInserted() called!
WEBSHELL+ = 2
FCC: ContentInserted() called!
FCC: ContentAppended() called!
FCC: ContentAppended() called!
FCC: ContentAppended() called!
FCC: ContentAppended() called!

Comment 2

[vidur (gone)]

I couldn't reproduce the slow, incorrect case. I'm fairly certain that the
ContentRemoved is not because of the sink - the only removal that should happen
would be as a result of a malformed FORM tag, and that's no the case in this
example. Passing back to Troy for further investigation per our conversation.

Comment 3

[troy]

So a big problem here is code Kipp added that if it sees a block inside of
an inline frame will discard and recreate that part of the frame model.

In this case what happens is that we discard an entire table cell and recreate
it. That causes serious performance problems

nsCSSFrameConstructor::ContentRemoved(nsCSSFrameConstructor * const 0x02339d18,
nsIPresContext * 0x023066e0, nsIContent * 0x02345cec, nsIContent * 0x02345dd0,
int 0) line 6454
nsCSSFrameConstructor::ContentReplaced(nsCSSFrameConstructor * const 0x02339d18,
nsIPresContext * 0x023066e0, nsIContent * 0x02345cec, nsIContent * 0x02345dd0,
nsIContent * 0x02345dd0, int 0) line 6277 + 28 bytes
nsCSSFrameConstructor::ReframeContainingBlock(nsIPresContext * 0x023066e0,
nsIFrame * 0x0243bfc4) line 10006 + 47 bytes
nsCSSFrameConstructor::ContentAppended(nsCSSFrameConstructor * const 0x02339d18,
nsIPresContext * 0x023066e0, nsIContent * 0x02345e54, int 31) line 5611 + 16
bytes
StyleSetImpl::ContentAppended(StyleSetImpl * const 0x02339c68, nsIPresContext *
0x023066e0, nsIContent * 0x02345e54, int 31) line 939
PresShell::ContentAppended(PresShell * const 0x023419a0, nsIDocument *
0x013e48e8, nsIContent * 0x02345e54, int 31) line 2395 + 46 bytes
nsDocument::ContentAppended(nsDocument * const 0x013e48e8, nsIContent *
0x02345e54, int 31) line 1545
nsHTMLDocument::ContentAppended(nsHTMLDocument * const 0x013e48e8, nsIContent *
0x02345e54, int 31) line 1112
HTMLContentSink::NotifyAppend(nsIContent * 0x02345e54, int 31) line 3721
SinkContext::CloseContainer(const nsIParserNode & {...}) line 1292
HTMLContentSink::CloseContainer(HTMLContentSink * const 0x013e9d50, const
nsIParserNode & {...}) line 2777 + 15 bytes
CNavDTD::CloseContainer(const nsIParserNode * 0x023ab088, nsHTMLTag
eHTMLTag_nobr, int 0) line 2972 + 31 bytes
CNavDTD::CloseContainersTo(int 6, nsHTMLTag eHTMLTag_nobr, int 0) line 3008 + 20
bytes
CNavDTD::CloseContainersTo(nsHTMLTag eHTMLTag_nobr, int 0) line 3160 + 20 bytes
CNavDTD::HandleEndToken(CToken * 0x023fd910) line 1657 + 20 bytes
CNavDTD::HandleToken(CNavDTD * const 0x01357e88, CToken * 0x023fd910, nsIParser
* 0x013e9660) line 804 + 12 bytes

Comment 4

[buster]

changing the subject to describe the root cause.  Tentatively setting to M16.
See nsCSSFrameConstructor::ConstructInline() and it's calls to
SetFrameIsSpecial(), and the various calls to IsFrameSpecial() that lead to very
expensive calls to ReframeContainingBlock().

Comment 5

[buster]

this is probably a dup of the WipeContainingBlock perf bug 18366.

Comment 6

[buster]

mine! mine mine mine!  all mine!  whoo-hoo!

Comment 7

[buster]

nisheeth is taking these and all related bugs.  poor guy.

Comment 8

[Nisheeth Ranjan]

Bringing this in to M15...

Comment 9

[Nisheeth Ranjan]

Moving bugs out by one milestone...

Comment 10

[Chris Waterson]

taking

Comment 11

[Chris Waterson]

The performance on this page is fine now AFAICT. I've been fixing some of the
inline block stuff; maybe a fix magically fell out of those changes.

Comment 12

[Chris Petersen]

Fixed in the July 14th build.