JDK-4286216 : Supressing resize events during win re-sizing precludes SELECTIVE repaint
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 1999-10-29
  • Updated: 2000-07-05
  • Resolved: 2000-07-05
Related Reports
Duplicate :  
Description

Name: krT82822			Date: 10/29/99


orig synopsis:  "Resize events are surpressed whilst frame is being resized"

10/29/99 eval1127@eng -- user's point appears to be that there should be a third alternative (between the extremes of no repainting or excessive repainting):
the option to selectively/intelligently repaint, based (only) on getting resize events (and not on repaint events).  This is designed to make the UI as "natural"
and "dynamic" as possible on the given platform, under the control of the application programmer.

java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)
Both Windows 95 and Windows NT allow windows to reflow their contents _during_
a resize operation. This is what users expect to see. It looks cool and it
gives the user visual feedback on the results of the resize operation.

However, in Java, when resizing a window, by dragging the edge with a mouse,
the layout remains frozen until the mouse button is released.

This looks totally *lame*. I thought it was a bug until I saw this comment in
bug report number 4025609

" Thanks for noticing, Bill, as it took some work to make this feature work.
Java can't handle the flood of resize and repaint messages that come through
normally in any sort of real time, so resize dragging was modified to reduce
the load. "

This was never justified because of bug 4174831, which has only just been fixed
in 1.3beta, this bug caused paint messages to be sent instead of resize
messages, which of course totally defeated the purpose of this "feature".

(It is interesting to note that these repaint messages were of the worst
possible kind, they totally cleared the background of the frame.)

That was back in January 1997, today computers are faster, Java VMs are faster,
Java programmers are writing better code. (And you've fixed bug 4174831)

Please kill this feature, or at least make it switchable with a command line
parameter or better yet something like frame.setDynamicResizing(true);

Microsoft's VM does send resize messages during a "resize dragging" and
therefore does reflow (or re-layout) its contents.

I have tested my application using Microsofts VM and there is no problem
whatsoever with handling the "flood" of resize messages.

Please please please fix this.
Until you do : All Java applications will look lame.

Thanks.

David Campaign
(Review ID: 97197) 
======================================================================

Comments
WORK AROUND Name: krT82822 Date: 10/29/99 ======================================================================
11-06-2004