While profiling some long pages (cf. bug 56854), I discovered that we're making many, many calls to Invalidate() from nsTextFrame::Reflow(). I vaguely recall kin & buster adding removing some conditionals here. Logging a task to investigate to see if we can reduce the number of invalidates required.

The only invalidation stuff I remember tweaking in nsTextFrame::Reflow() had to do with the fact that in some cases we were invalidating the wrong area on the screen (wrong coordinates), and sometimes we weren't invalidating all that we should've.

I'm futuring this bug because I'm not going to get to it before mozilla-1.0.

Comments from bug 116437, which is about a 24MB file taking forever to layout. The jprof is at http://bugzilla.mozilla.org/showattachment.cgi?attach_id=65191 Shows 3% from Invalidate(). Typical: Mostly Reflowing lines: 12% direct (90% total) in ReflowDirtyLines() 4% total in nsFontCache::GetMetricsFor() 6% direct in nsBlockReflowState::RecoverStateFrom() 2% direct in nsBlockFrame::PropagateFloaterDamage() 3% total in nsFrame::Invalidate() 10% direct in nsLineBox::GetCombinedArea() 4% direct, 13% total in nsBlockFrame::ComputeFinalSize() 6% direct in nsBlockFrame::BuildFloaterList() 8% total in nsBlockFrame::PlaceLine() 1.5% total in nsCSSRendering::FindBackground 3% total in nsHTMLReflowState::nsHTMLReflowState 5% direct in nsFrameList::LastChild 10% total in nsRenderingContextGTK::GetTextDimensions()

roc, how are things nowadays with the modern TextFrame?

Not much different, but I don't know if this is still really a problem.

(In reply to comment #5) > Not much different, but I don't know if this is still really a problem. I've seen several samples of hangs in Camino lately that show lots of reflow calls, specifically those in bug 418388. I'm not sure if that's the same basic cause or not, but I'm sure you have a much better idea than I do, roc.