turn paint flashing on make the window bigger you see the whole window flash a multitude of times (>1, at least). i don't know why we should reflow/repaint the main window more than once. assigning to brendan because i have no idea who should own this bug.

taking back, so i have all these bugs in one place.

accepting

this happens even if the sidebar is closed. cc'ing shaver per his request.

Twice is not enough :-) Putting on [PDT-] radar.

reassigning to brendan since i'm going on vacation.

Bulk-reassigning pink's "paint" bugs. /be

Kevin -- here's a paint bug. We'll load balance after the thursday meeting.

Fixed in Nov 2, 1999 4:52PM build. I removed the nsHTMLFrameInnerFrame::Reflow's call to mWebShell->Repaint. The repainting of the webshell is taken care of by the mWebShell->SetBounds call. The SetBounds call results in a nsIWidget::Resize which will generate a NS_SIZE event which the view manager will use to the root view's dimensions and perform a ResizeReflow which will invalidate the window. The mWebShell->Repaint was redundant and was causing the double paints of the content window in Mozilla. Note: Paint flashing is done for invalidates, not paints. The window looks like it is still being invalidated twice, but this is combined into a single paint. I verified this by setting a break point in the debugger. I'm marking this bug fixed because doing multiple invalidates is not a performance issue as long as their combined into a single paint for the same region. All of my work was on WIN32 but this bug was present on both Mac and WIN32 and involved XP-CODE.

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

actually on both mac and linux, paint flashing flashes on _paint_ not on invalidate.

That's true on WIN32 as well. I was mistaken. I was getting multiple paint flashes but only a single paint message so I wrongly assumed that the flashing was being done on invalidates. It turns out that On WIN32 paint messages are generated for child widgets associated with each webshell. These paint messages are not processed so their is very little overhead. If I filter these paint messages out, paint flashing gives a much more accurate picture of what is being refreshed. It turns out there are very few places that we are actually repainting more than we need to.. Work needs to be done on Linux and Mac to filter out the "paint flashing" noise.

a paint of a child window is still a paint and is causing taking more cycles than it needs to be. we shouldn't just ignore them, because they are happening. we should fix them all together if possible.

Adding verifyme keyword.

Verified fixed MozMacM14 (2000022108) OS 9. Pink's "paint" plagues no more! (Sorry, couldn't resist :)