Very strange drawImage(xyxyxyxy) behaviour

Hi… I’m getting some very strange behaviour (=completely broken) for a drawImage call. I’ve managed to scale the thing down to this file. Could someone test the following class and tell me if it works properly?


public class Bug extends Frame {
    
  public static void main(String[] x) {
    new Bug();
  }
  
  public Bug() {
    setBounds(0,0,1024,768);
    setVisible(true);
    addWindowListener(
        new WindowAdapter() {
          public void windowClosing(WindowEvent e) {
            System.exit(0);
          }
        }
        );
  }
    
  public void paint(Graphics gg) {
    BufferedImage img = getGraphicsConfiguration().createCompatibleImage(32,32,Transparency.OPAQUE);
    Graphics2D gImg = img.createGraphics();
    gImg.setColor(Color.red);
    gImg.fillOval(4,4,24,24);
    gImg.setColor(new Color(0x0));
    gImg.drawOval(4,4,24,24);
    
    gg.drawImage(img,200,200,200+15,200+15,0,0,31,31,null);
    }
}


I get garbage on Windows (and a huge amount of it) with these combinations:
BufferedImage img = getGraphicsConfiguration().createCompatibleImage(32,32,Transparency.OPAQUE);
BufferedImage img = getGraphicsConfiguration().createCompatibleImage(32,32,Transparency.BITMASK);
BufferedImage img = new BufferedImage(32,32,BufferedImage.TYPE_INT_RGB);

I get a proper result with :
BufferedImage img = getGraphicsConfiguration().createCompatibleImage(32,32,Transparency.TRANSLUCENT);
BufferedImage img = new BufferedImage(32,32,BufferedImage.TYPE_INT_ARGB);

In Linux both things seem to work (same hardware)

Thanks in advance!

I see garbage as well.

winxp

java version “1.5.0_02”
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
Java HotSpot™ Client VM (build 1.5.0_02-b09, mixed mode, sharing)

gg.drawImage(img,200,200,200+15,200+15,0,0,31,31,null);

The “null” could pose problems!? Try to use “this” instead - see if the problem is still there…

The null is who gets notified of image progress, it should be (and in this case is) irrelevant.
Seems a problem with the BitBlt software routines. I’ll test if this happens with Java 6 and file a bug if it does.

I have Java 6 and also get garbage. I guess you can file a bug.

Thanks! I’ll do it…

Hm. Works fine for me with jdk6.

What’s your desktop depth?

Dmitri

mine is 32bit, 1024x768, ati x800…
used jre6 I think, just like described, when using original it doesn’t work, using .TRANSLUCENT it works (no garbage around circle as I remember)

Works fine for me. I see a small black square with a red circle in it.

Windows XP Pro

java version “1.5.0_10”
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot™ Client VM (build 1.5.0_10-b03, mixed mode, sharing)

It could be a driver issue. Make sure your video card drivers are up to date.

the black square is garbage… you didn’t try workaround. Instead of OPAQUE put TRANSLUCENT and you’ll see that image changes, the black square disappears and only red circle is visible.

I don’t consider the black square garbage. If you make a BufferedImage opaque, then some colour has to be drawn for every pixel that it covers. Since BufferedImages store their information in an array of primitives(byte, int, etc) then they are defaulted to 0 unless you overwrite them. Since 0 red, 0 green and 0 blue is black, that is what is drawn. Every type that ahristov presented gave me results that I would expect.

By garbage he means it has funny colors

No problems with jre 1.5.0_07…

Kova said the black square is the garbage. In my earlier post I said that it looked fine for me with no funny colours.

I also tried it on a Windows NT machine with:
java version “1.5.0_10”
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot™ Client VM (build 1.5.0_10-b03, mixed mode, sharing)

It works fine for me there as well. So that is why I am thinking it is a driver issue.

sorry, I put it very bad, as I remember it had some funny colors around circle, not black square itself

No problem. I wasn’t sure if I understood the question. Now it seems clear.