this is a tracking bug to investigate mail/news thread pane performance, for things like scrolling.

So far, I've determined that scrolling the thread pane causes the whole 3-pane to get redrawn (not good, and quite possibly because of the coalescing of invalid regions which is being worked on). Also, it seems like we're painting the tree cells roughly 5-10 times more often than we should (repainting the folder pane might account for a good chunk of these paints). I'm trying to track down who's invalidating a region outside the thread pane but it's tricky. It could be something silly like focus or selection.

accidentally marked fixed -whoops. I've verified that we're only creating one html reflow command for the thread pane when we page with the scroll bar, and that reflow command somehow causes an invalidation of the whole window. Here's a stack trace where this happens. In particular, nsBoxFrame::FlowChildren seems to invalidate the whole window on purpose (though I'm never sure what coordinates we're talking about). Cc'ing evaughan, since I think nsBoxFrame is his. nsWindow::Invalidate(nsWindow * const 0x01cfeee4, const nsRect & {...}, int 0x00000000) line 1474 nsViewManager::UpdateDirtyViews(nsIView * 0x01cfd110, nsRect * 0x0012e6fc) line 1364 nsViewManager::UpdateView(nsViewManager * const 0x01cfd2e0, nsIView * 0x01cfd110, const nsRect & {...}, unsigned int 0x00000004) line 1532 nsFrame::Invalidate(nsIPresContext * 0x01076820, const nsRect & {...}, int 0x00000000) line 1615 nsBoxFrame::FlowChildren(nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0x00000000, nsRect & {...}) line 680 nsBoxFrame::Reflow(nsBoxFrame * const 0x020d33a0, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0x00000000) line 508 nsBoxFrame::FlowChildAt(nsIFrame * 0x020d33a0, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0x00000000, nsCalculatedBoxInfo & {...}, int & 0x00000000, nsString & {...}) line 1072 nsBoxFrame::FlowChildren(nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0x00000000, nsRect & {...}) line 646 nsBoxFrame::Reflow(nsBoxFrame * const 0x00e926b0, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0x00000000) line 508 nsContainerFrame::ReflowChild(nsIFrame * 0x00e926b0, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0x00000000) line 405 + 31 bytes RootFrame::Reflow(RootFrame * const 0x024f16c0, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0x00000000) line 332 nsContainerFrame::ReflowChild(nsIFrame * 0x024f16c0, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0x00000000) line 405 + 31 bytes ViewportFrame::Reflow(ViewportFrame * const 0x024f19f0, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0x00000000) line 514 nsHTMLReflowCommand::Dispatch(nsHTMLReflowCommand * const 0x02cc4450, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsSize & {...}, nsIRenderingContext & {...}) line 140

Perhaps this is all by design - it looks like nsHTMLReflowCommand::Dispatch deliberately reflows from the root, I guess to deal with the problem of children resizing as a result of reflow? So, to prevent this problem, we'd need to either have a way of not reflowing from the root when we know that the reflow is not going to resize the target frame, or not invalidate areas that didn't resize as a result of reflow. The former would be better, because we'd save all the extra reflows. I'm going to leave this for now, until I get some advice in people in the know, in case I'm way off in left field.

moving to m13 - hyatt and waterson are really doing the work here, focusing on the tree control performance.

*** Bug 20695 has been marked as a duplicate of this bug. ***

Thats too bad that this is not considered dogfood because on my machine nt4sp5 the threadpane performance is ridiculously slow. I am able to use the browser but mail/news is too slow for me to do any sort of real work in. I would say that if i click on the down arrow it takes atleast one second to redraw the pane. I can post more info if you would like.

reassigning to hyatt and moving to m14 - this has gotten a lot better, thanks to Dave.

Adding perf to keyword field.

*** Bug 21592 has been marked as a duplicate of this bug. ***

Mass-moving all M16 non-feature bugs to M17, which we now consider to be part of beta2.

m18

Mass-moving all bugs to M21 that are not dogfood+, nsbeta2+, or nsbeta2-

CLosing this ancient bug. I will obviously keep investigating and profiling, btu I don't need an individual bug just for mailnews.

Linux (2000-08-25-08 M18) Win32 (2000-08-25-08 M18) Mac (2000-08-25-08 M18) Based on the original bug report, this bug does not exist in the new builds.