Win32 - Problems with resizing Apprunner window

VERIFIED DUPLICATE of bug 12234

Status

()

P3
normal
VERIFIED DUPLICATE of bug 12234
20 years ago
18 years ago

People

(Reporter: cpratt, Assigned: kmcclusk)

Tracking

({perf, platform-parity})

Trunk
mozilla0.9
x86
Windows NT
perf, platform-parity
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
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

20 years ago
Assignee: beard → joki
Component: Compositor → Event Handling

Comment 1

20 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.

Updated

20 years ago
Summary: [PERF][PP] Win32 - Problems with resizing Apprunner window → [PP] Win32 - Problems with resizing Apprunner window
Whiteboard: [Perf]

Comment 2

20 years ago
Putting on [Perf] radar per Status Whiteboard (where this belongs for queries)

Updated

19 years ago
Target Milestone: M15
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.

Updated

19 years ago
Keywords: perf

Comment 4

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

Updated

19 years ago
Keywords: pp

Comment 5

19 years ago
Is this still a problem; i.e., distinct from general window resize/reflow (see 
e.g. bug 4545)?

Comment 6

19 years ago
Performance on this seems fine to me, better than 4.7 on Win98, even on more 
complex pages. 

Comment 7

19 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

19 years ago
Summary: [PP] Win32 - Problems with resizing Apprunner window → Win32 - Problems with resizing Apprunner window
Whiteboard: [Perf]
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 8

19 years ago
Bulk moving to M16
(Assignee)

Updated

19 years ago
Target Milestone: M15 → M16

Updated

19 years ago
Target Milestone: M16 → M17
(Assignee)

Comment 9

19 years ago
Moving to M18
Target Milestone: M17 → M18
(Assignee)

Comment 10

19 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

19 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

18 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

18 years ago

*** 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

Comment 14

18 years ago
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.