Build ID: 1999090808 Platform: Windows NT (this bug is specific to Win32) To reproduce: - Launch apprunner - Press Alt-Space to bring up the window menu - Press S to resize the window - Use the arrow keys (cursor keys) to resize the window Result: If you change the width of the window, it happens very slowly. The throbber paints and repaints itself in different places with every increment of resizing; in fact, all objects along the right hand side of the window paint twice and then redraw correctly. If you change the height of the window, everything along the bottom border of the window jerks along in the same manner. Expected result: Performance should be no worse than Communicator 4.x, and the objects along the border of the window should not repaint themselves.
Assignee: beard → joki
Component: Compositor → Event Handling
This is really an event handling problem. Perhaps we should wait until the window is no longer being resized until we issue the reflows. It's also highly platform- specific.
Summary: [PERF][PP] Win32 - Problems with resizing Apprunner window → [PP] Win32 - Problems with resizing Apprunner window
Putting on [Perf] radar per Status Whiteboard (where this belongs for queries)
It's an acceptable speed for me on M13 build 1999122308 on Win98. With Alt+Space,S you can't really wait until the user finishes resizing anyway, because no other app does that. You could do something like scheduling reflows at no more than one a second, though.
Bulk add of "perf" to new keyword field. This will replace the [PERF] we were using in the Status Summary field.
Is this still a problem; i.e., distinct from general window resize/reflow (see e.g. bug 4545)?
Performance on this seems fine to me, better than 4.7 on Win98, even on more complex pages.
I'd say its still a problem. Its specific to keyboard resize on Windows. If you mouse resize we're fine but keyboard resize feels really clunky as we stop to reflow after each key message. Just try 4 vs 5 and see. However, upon looking at it again I think this lives wholly in the Windows widget. We need to use a timer or something to better our speed on this. I'm going to reassign to a widget guy.
Assignee: joki → kmcclusk
Summary: [PP] Win32 - Problems with resizing Apprunner window → Win32 - Problems with resizing Apprunner window
Bulk moving to M16
Moving to M18
Target Milestone: M17 → M18
Using the keyboard to resize the window it speeds up once the window is made narrower than the beginning of the URL bar. If I grab the outside of the window with the mouse pointer and resize, it is fast regardless of the width of the window.
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M18 → Future
The slow down occurs when the vertical scrollbar is visible. When the window is too narrow for the vertical scrollbar to display it is resizes twice as fast as when the vertical scrollbar is visible. When the vertical scrollbar is visible each resize causes the document to lay'ed out twice. Once without the vertical scrollbar and then with it. This explains why it's twice as slow. Its doing twice as many reflows and paints when the vertical scrollbar is visible.
*** This bug has been marked as a duplicate of 12234 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
Target Milestone: Future → mozilla0.9
Verifications. Tests (if necessary) were done with 2001052504 on Windows 2000. Please forgive the spam.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.