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

VERIFIED FIXED in M17

Status

()

Core
Layout
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: rothwell, Assigned: Chris Waterson)

Tracking

({perf})

Trunk
Other
Other
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 years ago
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.

Updated

18 years ago
Assignee: troy → vidur

Comment 1

18 years ago
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!

Updated

18 years ago
Assignee: vidur → troy

Comment 2

18 years ago
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.

Updated

18 years ago
Assignee: troy → kipp

Comment 3

18 years ago
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

Updated

18 years ago
Summary: Slow, incorrect layout → [PERF] Incremental Reflows of "special" frames are slow
Target Milestone: M16

Comment 4

18 years ago
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().

Updated

18 years ago
Keywords: perf
Summary: [PERF] Incremental Reflows of "special" frames are slow → Incremental Reflows of "special" frames are slow

Comment 5

18 years ago
this is probably a dup of the WipeContainingBlock perf bug 18366.
Depends on: 18366
Summary: Incremental Reflows of "special" frames are slow → Incremental Reflows of "special" frames are slow (WipeContainingBlock)

Comment 6

18 years ago
mine! mine mine mine!  all mine!  whoo-hoo!
Assignee: kipp → buster

Comment 7

18 years ago
nisheeth is taking these and all related bugs.  poor guy.
Assignee: buster → nisheeth

Comment 8

18 years ago
Bringing this in to M15...
Status: NEW → ASSIGNED
Target Milestone: M16 → M15

Comment 9

18 years ago
Moving bugs out by one milestone...
Target Milestone: M15 → M16

Updated

18 years ago
Blocks: 40246
(Assignee)

Comment 10

18 years ago
taking
Assignee: nisheeth → waterson
Status: ASSIGNED → NEW
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

18 years ago
Target Milestone: M16 → M17
(Assignee)

Comment 11

18 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 12

18 years ago
Fixed in the July 14th build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.