Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4286216

Supressing resize events during win re-sizing precludes SELECTIVE repaint

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: P4 P4
    • None
    • 1.3.0
    • client-libs
    • generic
    • generic



      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)
      ======================================================================

            ehawkessunw Eric Hawkes (Inactive)
            kryansunw Kevin Ryan (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: