13371 - Win32 - Problems with resizing Apprunner window

Status: VERIFIED DUPLICATE of bug 12234

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[cpratt]

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.

Comment 1

[Patrick C. Beard]

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.

Comment 2

[leger]

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

Comment 3

[Matthew T (active 1999-2002)]

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.

Comment 4

[leger]

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

Comment 5

[Chris Waterson]

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

Comment 6

[Peter Trudelle]

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

Comment 7

[joki (gone)]

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.

Comment 8

[Kevin McCluskey (gone)]

Bulk moving to M16

Comment 9

[Kevin McCluskey (gone)]

Moving to M18

Comment 10

[Kevin McCluskey (gone)]

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.

Comment 11

[Kevin McCluskey (gone)]

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. 

Comment 12

[Kevin McCluskey (gone)]

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.

Comment 13

[Kevin McCluskey (gone)]

*** This bug has been marked as a duplicate of 12234 ***

Comment 14

[Chad Austin]

Verifications.  Tests (if necessary) were done with 2001052504 on Windows 2000.

Please forgive the spam.