Closed
Bug 68179
Opened 24 years ago
Closed 24 years ago
evaluate whether nsLineLayout::ReflowFrame()'s crawl to root is expensive
Categories
(Core :: Layout, defect)
Tracking
()
VERIFIED
INVALID
mozilla0.9
People
(Reporter: waterson, Assigned: waterson)
References
Details
(Keywords: perf)
To fix bug 45152, buster added code in nsLineLayout::ReflowFrame() that will crawl to the root of the frame tree every time we do an initial reflow on a text frame. This might be a plausible explanation for bug 60444. Anyway, this is a placeholder, reminding me to 1. Temporarily move that code out into a separate function (so that Quantify can account for it). 2. Profile some page layout, and see if a noticable amount of time is spent in the code. If it is, we could possibly set a bit in the frame flags (NS_FRAME_IN_TEXT_WIDGET) during frame construction or something.
Assignee | ||
Updated•24 years ago
|
Assignee | ||
Comment 1•24 years ago
|
||
Oh good grief. I just read the code: if (eReflowReason_Initial == reflowState.reason) { if (frameType && nsLayoutAtoms::textFrame == frameType.get()) { } } So we're only doing this on a text frame's initial reflow. For some reason, I thought we were doing it all the time. But maybe I was thinking of nsBlockFrame::IsIncrementalDamageConstrained()? Anyway, I'm going to stop this witch hunt, and wait for the problem to show up somewhere.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•