there are two levels to the problem. 1) there is a bug in gtk where gtk_layout's thaw method generates a synchronous repaint of the whole window when called. we call this by invoking nsIWidget::EndResizingChildren. 2) we can avoid this call by moving the call to nsIView::SetPosition in the nsViewManager::MoveViewTo (and possibly MoveViewBy if there is one) inside the if() test near the top of the method rather than calling it unconditionally. but, if we do #2, some things get busted because they position theire views, then create widgets and recall SetPosition to get the widget synched with the view (this is my guess - in concrete, mail/news in the apprunner gets busted). we need to find a way to fix both #1 and #2 i think, but #1 really must be fixed.

meant to reassign it to the new owner and got mixed up. oops.

should this go to ramiro?

ramiro has a bug about the gtk thing.

-> M6

This is a performance issue, but may involve some global changes to implement correctly.

moving to m9. beard's on vacation

Just verifying that this still happens with Linux build 1999080408

Bulk add of "perf" to new keyword field. This will replace the [PERF] we were using in the Status Summary field.

This bug is related to or a possibly a dup of bug 19388

Reassigning all view bugs to kevin.

Eric, I think this bug will be fixed by your changes to batch moving and resizing of nsIWidgets in the viewmanager. If your change doesn't fix this, reassign back to me.

Mass moving M17 bugs to M18

Widget coelescing makes no difference the window is still invalidated everytime.

There is only one place that we call nsIWidget::EndResizingChildren() and that is nsScrollingView.cpp. nsScrollingView.cpp is only used for native scrollbars. Since we have switched to gfx-scrollbars we never call nsIWidget::EndResizingChildren so this can not be a performance issue for GTK. The most likely culprit is the timer implementation on GTK. This is covered by bug 34871. I'm marking this bug WONT FIX since it is out of date.

Marking verified won't fix.

Michael Lowe's implemention was intended to starve the timers, so all paint and reflow events would be processed before another timer would fire. This was to ensure the following sequence: 1) timer_callback 2) scheduling of reflow + paint events + timer events (Result of JavaScript manipulation of the DOM) 3) reflow + paint events are processed 4) timer_callback (scheduled by action 2) The GTK implementation was supposedly changed to also starve the timer events in this way.