Closed Bug 4807 Opened 26 years ago Closed 24 years ago

demo13 runs slower than it should

Categories

(Core :: Web Painting, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED WONTFIX

People

(Reporter: michaelp, Assigned: kmcclusk)

References

Details

(Keywords: perf, platform-parity)

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.
Assignee: kmcclusk → beard
meant to reassign it to the new owner and got mixed up. oops.
Status: NEW → ASSIGNED
Target Milestone: M5
should this go to ramiro?
ramiro has a bug about the gtk thing.
Summary: runs slower than it should → [PP]runs slower than it should
Target Milestone: M5 → M6
-> M6
Target Milestone: M6 → M8
This is a performance issue, but may involve some global changes to implement correctly.
Whiteboard: [Perf]
Blocks: 8691
Summary: [PP]runs slower than it should → [PP] demo13 runs slower than it should
moving to m9. beard's on vacation
Just verifying that this still happens with Linux build 1999080408
Target Milestone: M9 → M10
Target Milestone: M10 → M12
Target Milestone: M12 → M13
Keywords: perf
Bulk add of "perf" to new keyword field. This will replace the [PERF] we were using in the Status Summary field.
Target Milestone: M13 → M15
Keywords: pp
Summary: [PP] demo13 runs slower than it should → demo13 runs slower than it should
Whiteboard: [Perf]
This bug is related to or a possibly a dup of bug 19388
Reassigning all view bugs to kevin.
Assignee: beard → kmcclusk
Status: ASSIGNED → NEW
Component: Compositor → Views
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.
Assignee: kmcclusk → evaughan
Target Milestone: M15 → M17
Mass moving M17 bugs to M18
Target Milestone: M17 → M18
Widget coelescing makes no difference the window is still invalidated everytime.
Assignee: evaughan → kmcclusk
Status: NEW → ASSIGNED
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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Marking verified won't fix.
Status: RESOLVED → VERIFIED
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.
URL: demo13
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.