Closed
Bug 4807
Opened 26 years ago
Closed 24 years ago
demo13 runs slower than it should
Categories
(Core :: Web Painting, defect, P3)
Tracking
()
VERIFIED
WONTFIX
M18
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.
meant to reassign it to the new owner and got mixed up. oops.
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M5
Comment 2•26 years ago
|
||
should this go to ramiro?
Updated•25 years ago
|
Target Milestone: M5 → M6
Comment 4•25 years ago
|
||
-> M6
Updated•25 years ago
|
Target Milestone: M6 → M8
Comment 5•25 years ago
|
||
This is a performance issue, but may involve some global changes to implement
correctly.
Updated•25 years ago
|
Blocks: 8691
Summary: [PP]runs slower than it should → [PP] demo13 runs slower than it should
Comment 6•25 years ago
|
||
moving to m9. beard's on vacation
Comment 7•25 years ago
|
||
Just verifying that this still happens with Linux build 1999080408
Updated•25 years ago
|
Target Milestone: M9 → M10
Updated•25 years ago
|
Target Milestone: M10 → M12
Updated•25 years ago
|
Target Milestone: M12 → M13
Bulk add of "perf" to new keyword field. This will replace the [PERF] we were
using in the Status Summary field.
Updated•25 years ago
|
Target Milestone: M13 → M15
Updated•25 years ago
|
Summary: [PP] demo13 runs slower than it should → demo13 runs slower than it should
Whiteboard: [Perf]
Comment 10•25 years ago
|
||
Reassigning all view bugs to kevin.
Assignee: beard → kmcclusk
Status: ASSIGNED → NEW
Component: Compositor → Views
Assignee | ||
Comment 11•25 years ago
|
||
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
Comment 13•24 years ago
|
||
Widget coelescing makes no difference the window is still invalidated everytime.
Assignee: evaughan → kmcclusk
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 14•24 years ago
|
||
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
Assignee | ||
Comment 16•23 years ago
|
||
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.
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•