120780 - Constantly invalidating entire download window

Status: RESOLVED INCOMPLETE

(Core :: Layout, defect, P3)

Description

[Mike Pinkerton (not reading bugmail)]

Downloading a file pegs the cpu. This is probably because the progress bar is
being re-drawn too often.

Comment 1

[Mike Pinkerton (not reading bugmail)]

this also happens in modern actually. I sampled it and here is the breakdown:

50% processing PLEvents (downloading)
50% handling mac events
  98% in eventAvail dealing with updating the window server
  2% redrawing the edit text areas

Why is it even redrawing the text areas you might ask? well in the classic
theme, the ENTIRE download window is repainted every time anything updates. In
modern it's only slightly better, everything but the bottom row of buttons is
redrawn. This is really easy to see if you turn on quartz debugging and flash
screen updates.

I broke at where we're performing the whole-window invalidate:

0  nsWindow::Invalidate (this=0x13a22520, aRect=@0xbfffe228, aIsSynchronous=0)
at nsWindow.cpp:1021
#1  0x10fd45a0 in nsViewManager::UpdateAllCoveringWidgets (this=0x13a22350,
aView=0x13a224b0, aTarget=0x0, aDamagedRect=@0xbfffe2f4,
aRepaintOnlyUnblittableViews=0) at nsViewManager.cpp:1579
#2  0x10fd491c in nsViewManager::UpdateView (this=0x13a22350, aView=0x13a224b0,
aRect=@0xbfffe3b8, aUpdateFlags=4) at nsViewManager.cpp:1659
#3  0x0fb3da88 in nsBox::Redraw (this=0x14ba52ac, aState=@0xbfffed98,
aDamageRect=0x0, aImmediate=0) at nsBox.cpp:1206
#4  0x0fb4a234 in nsSprocketLayout::Layout (this=0x14ba6110, aBox=0x14ba52ac,
aState=@0xbfffed98) at nsSprocketLayout.cpp:685
#5  0x0fb46f98 in nsContainerBox::DoLayout (this=0x14ba52ac, aState=@0xbfffed98)
at nsContainerBox.cpp:610
#6  0x0fb5f184 in nsBoxFrame::DoLayout (this=0x14ba5274, aState=@0xbfffed98) at
nsBoxFrame.cpp:1150
#7  0x0fb3d2a4 in nsBox::Layout (this=0x14ba52ac, aState=@0xbfffed98) at
nsBox.cpp:1050
#8  0x0fb4e6c8 in nsStackLayout::Layout (this=0x14e89510, aBox=0x14ba5138,
aState=@0xbfffed98) at nsStackLayout.cpp:328
#9  0x0fbff2c4 in nsGridLayout2::Layout (this=0x14e89510, aBox=0x14ba5138,
aBoxLayoutState=@0xbfffed98) at nsGridLayout2.cpp:69
#10 0x0fb46f98 in nsContainerBox::DoLayout (this=0x14ba5138, aState=@0xbfffed98)
at nsContainerBox.cpp:610
...

What appears to be happening is that something tells box it has to reflow and
redraw, it goes and gets its view, which invalidates its widget. The bounds of
this widget are (7,7,458,179) [left,top,right,bottom] which is pretty much the
entire download window.

So this really doesn't have anything to do with the theme stuff and everything
to do with layout doing the wrong thing.

Comment 2

[Mike Pinkerton (not reading bugmail)]

i just did another test, this time with the prefs window. clicking in a single
radio button redraws the _entire_ window. However, it is partially related to
the theme stuff. Modern only redraws the localized area, as does classic with
the theme stuff turned off. However, with the theme stuff on in classic, the
entire pref panel is repainted with any click of the mouse on a button.

This can't be an impl detail of nsNativeThemeMac because I'm not invalidating
anything in my code. It must be in layout. Therefore, it's probably hyatt's.

This is very easy to see with the QuartzDebug app on OSX.

Comment 3

[Peter Trudelle]

nsbeta1- per nav triage

Comment 4

[Peter Trudelle]

Mass-moving all Navigator team 1.0 nsbeta1- bugs to 1.1

Comment 5

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.