4807 - demo13 runs slower than it should

Status: VERIFIED WONTFIX

(Core :: Web Painting, defect, P3)

Description

[michaelp]

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.

Comment 1

[michaelp]

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

Comment 2

[Patrick C. Beard]

should this go to ramiro?

Comment 3

[michaelp]

ramiro has a bug about the gtk thing.

Comment 4

[Patrick C. Beard]

-> M6

Comment 5

[Patrick C. Beard]

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

Comment 6

[chris hofmann]

moving to m9. beard's on vacation

Comment 7

[Jay Patel [:jay]]

Just verifying that this still happens with Linux build 1999080408

Comment 8

[leger]

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

Comment 9

[Kevin McCluskey (gone)]

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

Comment 10

[Patrick C. Beard]

Reassigning all view bugs to kevin.

Comment 11

[Kevin McCluskey (gone)]

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.

Comment 12

[Peter Trudelle]

Mass moving M17 bugs to M18

Comment 13

[Eric Vaughan]

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

Comment 14

[Kevin McCluskey (gone)]

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.

Comment 15

[Chris Petersen]

Marking verified won't fix.

Comment 16

[Kevin McCluskey (gone)]

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.