ategory: AWT

Priority: CRITICAL! (Low/Medium/High/Critical)

JDK version: JDK-1_0-win32-x86.exe

Platforms: Windows 95 [Version 4.00.950]


Synopsis
--------

Painting is scrambled on Windows 95 AWT. The effect is most obvious
with multiple frame windows.


Description
-----------

This bug occurs only on Windows95. It does not occur on Solaris or
WindowsNT.

Painting gets all messed up on Windows 95 when you have multiple top
level frame windows. The problem appears to be twofold:

1) The graphics context given in paint is incorrect
2) The location of the component is incorrect


Test Case
---------

- Compile and run paint.java:

  javac paint.java
  java paint

- Play around with the windows by moving them and resizing them.

  There are several categories of visibly apparent painting problems:

  * Some lines do not get painted at all
  * Some lines get painted in the wrong location
  * Some lines get painted in the wrong frame!

  Number 3 becomes obvious as you move the windows around while causing
  other windows to become exposed in the process.


----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: paint.java
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 85


import java.awt.*;

class BorderPanel extends Panel {
  private static final int borderWidth = 10;

  public Dimension minimumSize() {
    Dimension d;

    if (countComponents() > 0) {
      Component comp = getComponent(0);
      d = comp.minimumSize();
    }
    else {
      d = new Dimension(0, 0);
    }

    d.width += 2*borderWidth;
    d.height += 2*borderWidth;

    return d;
  }

  public Dimension preferredSize() {
    return minimumSize();
  }

  public void layout() {
    Dimension d = size();
    Component components[] = getComponents();

    for (int i=0; i<components.length; i++) {
      if (i==0) {
components[i].reshape(borderWidth, borderWidth,
d.width - 2*borderWidth,
d.height - 2*borderWidth);
      }
      else {
components[i].reshape(-1, -1, 0, 0);
      }
    }
  }

  public void paint(Graphics g) {
    // System.out.println("PAINT");
    Dimension d = size();
    g.drawRect(0, 0, d.width-1, d.height-1);
    g.drawRect(1, 1, d.width-3, d.height-3);
  }
}

class PaintFrame extends Frame {
  public PaintFrame() {
    Button button = new Button("Button");
    Panel p = new BorderPanel();
    createNestedPanels(button, p, 10);
    add("Center", p);

    show();
    resize(preferredSize());
    validate();
  }

  public void createNestedPanels(Component c, Panel parent, int num) {
    if (num == 0)
      parent.add(c);
    else {
      Panel bp = new BorderPanel();
      parent.add(bp);
      createNestedPanels(c, bp, num-1);
    }
  }
}

public class paint {
  public static void main(String argv[]) {
    for (int i=0; i<10; i++) {
      Frame f = new PaintFrame();
      f.show();
      Dimension d = f.preferredSize();
      f.reshape(i*50, i*50, d.width, d.height);
      f.validate();
    }
  }
}
_____
Windows-level debugging information and a slightly smaller if not more clear code example.
>From: Mark Florence <###@###.###>
This does not look like form output to me.


ENVIRONMENT
  JDK v1.0, Win95

HOST
  Both Netscape v2.0 and AppletViewer

OBSERVED SYMPTOMS
  Java components paint incorrectly, often painting outside of their =
extent, even on the Windows desktop.

SECONDARY SYMPTOMS=20
  Parts of hidden components are randomly visible.

OBSERVATION
  The AppletViewer is used to execute the failing Java code under the =
debugging Win95 kernel. WinDbg reports literally hundreds of violations, =
falling into three categories:

    1) err- SELECTOBJECT -- invalid HGDIOBJECT
    2) err- More than 32 timers created for task
    3) err- GetDC failed -- DC cache full

TEST CASE
import java.awt.*;

public class TestBadPaint extends java.applet.Applet {
  public void init() {
    setLayout(new GridLayout(8, 8, 2, 2));
    for (int i =3D 0; i < 64; i++)=20
      add(new BadBoy("BadBoy#" + i));
  }
}

class BadBoy extends Canvas {
  private String text;
  public BadBoy(String s) {
    super();
    text =3D s;
  }
  public boolean mouseDown(Event evt, int x, int y) {
    repaint();
    return true;
  }
  public synchronized void paint(Graphics g) {
    /* what we do here is irrelevant; this just makes the error visible =
*/
    g.setColor(Color.getHSBColor((float)Math.random(), 0.2f, 1.0f));
    g.fillRect(0, 0, size().width, size().height);
    g.setColor(getForeground());
    g.drawString(text, (size().width - =
g.getFontMetrics().stringWidth(text)) / 2,
      (size().height / 2) + (g.getFontMetrics().getAscent() / 2));
  }

}

RUNNING THE TEST CASE
1) Use an HTML tag something like this: <applet =
code=3D"TestBadPaint.class" width=3D640 height=3D640>
2) Launch it using the AppletViewer
3) Observe that in most cases the AppletViewer window is painted =
correctly, as an 8x8 grid of pastel colors, annotated left-to-right, =
top-to-bottom with "BadBoy#n".
4) Wash the window by dragging it off-screen, then back again.
5) Observe that a central block of the grid has not been painted.
6) Click on a square that has been correctly painted and observe that it =
is repainted correctly.
7) Click on any part of the unpainted area and observe that another area =
of the grid is erroneously repainted.
8) Use the Windows Spy++ "find window" facility to prove that the grid =
components are located correctly, just painted incorrectly.

Note that each time the AppletViewer is relaunched, a greater portion of =
the grid is displayed correctly. If (5) above cannot be observed, =
restart Windows and retry.

Please contact Mark Florence at ###@###.### for any additional =
details. Thank you for your attention in this matter.

-- Mark Florence
From: Mark Florence <###@###.###>
This does not look like form output to me.


Java applets repaint erratically under Win95. Borland have fixed this problem
in a new version of AWT.DLL, shipped in the pre-Beta version of their Latte
Java debugger.

These fixes should be incorporated into the next JDK, and distributed to Netscape
for inclusion in their code.

-- Mark Florence