Closed
Bug 13371
Opened 25 years ago
Closed 23 years ago
Win32 - Problems with resizing Apprunner window
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
mozilla0.9
People
(Reporter: cpratt, Assigned: kmcclusk)
Details
(Keywords: perf, platform-parity)
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.
Updated•25 years ago
|
Assignee: beard → joki
Component: Compositor → Event Handling
Comment 1•25 years ago
|
||
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
Whiteboard: [Perf]
Putting on [Perf] radar per Status Whiteboard (where this belongs for queries)
Updated•25 years ago
|
Target Milestone: M15
Comment 3•25 years ago
|
||
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.
Comment 5•25 years ago
|
||
Is this still a problem; i.e., distinct from general window resize/reflow (see e.g. bug 4545)?
Comment 6•25 years ago
|
||
Performance on this seems fine to me, better than 4.7 on Win98, even on more complex pages.
Comment 7•25 years ago
|
||
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
Updated•25 years ago
|
Summary: [PP] Win32 - Problems with resizing Apprunner window → Win32 - Problems with resizing Apprunner window
Whiteboard: [Perf]
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 8•24 years ago
|
||
Bulk moving to M16
Assignee | ||
Updated•24 years ago
|
Target Milestone: M15 → M16
Assignee | ||
Comment 10•24 years ago
|
||
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.
Assignee | ||
Comment 11•24 years ago
|
||
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
Assignee | ||
Comment 12•24 years ago
|
||
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.
Assignee | ||
Comment 13•23 years ago
|
||
*** This bug has been marked as a duplicate of 12234 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Target Milestone: Future → mozilla0.9
Comment 14•23 years ago
|
||
Verifications. Tests (if necessary) were done with 2001052504 on Windows 2000. Please forgive the spam.
Status: RESOLVED → VERIFIED
Updated•5 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•