Drawing Transparent Images in 1.4 is buggy

Java 2D
#1

Today i compiled a old game tool with 1.4 and found following feature / bug ?

        
BufferedImage aBufferedImage = new BufferedImage(width, height, BufferedImage.TYPE_INT_ARGB);

... write your data here in  BufferedImage ...

itsImage = Toolkit.getDefaultToolkit().createImage(aBufferedImage.getSource());

when u use transparent Pixels (Alpha Mask is 0x00) and paint Image its not painted where it should when i use TYPE_INT_RGB everything is ok when i use sun.java2d.noddraw=true everything is ok

Painting is done in ScrollPane, but that cant be the problem.

when u use TYPE_INT_ARGB x , y in translated -2,-2 so image apperas 2 pixels to the left and 2 pixel to the top

brb

took me 3 hours to find that nasty bug, i hope they will fix that in the next release

#2

Looks like a bug. You might also want to try -Dsun.java2d.ddoffscreen=false to confirm.
Have you tried 1.4.1_01?

Also, try just blitting the argb image to the image created with createCompatibleImage or ‘new BufferedImage’, it should be faster.

I assume you want the compatible image to be argb, too, right?
Then just use "new BufferedImage(w, h, TYPE_INT_ARGB), since the images created with createCompatibleImage(w,h,Translucency.TRANSLUCENT) are not currently accelerated anyway.

Something like this:

itsImage =
Graphics2D g2d = (Graphics2D)itsImage.getGraphics();
// g2s.setComposite(AlphaComposite.Src); - if you like
g2d.drawImage(aBufferedImage, 0, 0, null);

Why do you need this intermediate image in the first place?

#3

I am using the lastest JDK 1.4.1_01 on a Win98SE machine with PentiumIII (Geforce2MX/MX400 with 64MB)

and i modified my code now a little bit


... loading pixel data (special format)

// now create image from pixels
itsImage = gc.createCompatibleImage(width, height, Transparency.BITMASK);
BufferedImage aBufferedImage = (BufferedImage)itsImage; // <-- is this safe ????

... use setRGB to set only some pixels
aBufferedImage.setRGB(..);

aBufferedImage = null; // <-- is this needed ?

now we come to the funny part in a ScrollPane i draw the Image in paint() and i do not use an special Offscreen technic, first i call super.paint() then i do my g.drawImage on a Graphics Object

with Dsun.java2d.trace=log output is

sun.java2d.loops.Blit::Blit(IntArgbBm, SrcOverNoEa, Ushort565Rgb)

image is not drawn correctly i paint it on (11,11) but its displayed at (9,9)

then i click on my console created ( i use java not javaw ) but any other window will do fine 2.

the window will overlap and hide my image so when i return to my application screen must be redrawn

sun.awt.windows.Win32BlitLoops$DelegateBlitBgLoop::BlitBg(Any, SrcNoEa, “Short 5
65 RGB DirectDraw with 1 bit transp”)
sun.java2d.loops.SetFillRectANY::FillRect(AnyColor, SrcNoEa, Any)
sun.java2d.loops.Blit::Blit(IntArgbBm, SrcOverNoEa, Ushort565Rgb)
sun.java2d.loops.Blit::Blit(Ushort565Rgb, SrcNoEa, Ushort565Rgb)
sun.awt.windows.Win32BlitLoops::Blit("Short 565 RGB DirectDraw with 1 bit transp
", SrcOverNoEa, “Short 565 RGB DirectDraw”)

looks nice because now java uses hw acceleration
and image is now painted correctly at (10,10)

now i click again at my console window which comes to foreground and overlaps my application again and then i click again in my application , so my image and window must be redrawn

sun.java2d.loops.Blit::Blit(IntArgbBm, SrcOverNoEa, Ushort565Rgb)

hw acceleration is not used anymore, funny, but now i click again in my console it comes to foreground and overlapps my image and then switch back to my application

sun.awt.windows.Win32BlitLoops::Blit("Short 565 RGB DirectDraw with 1 bit transp
", SrcOverNoEa, “Short 565 RGB DirectDraw”)

what happened ? its now using hw acceleration again !!! and now u can click in console or move any other window over my image it will use hw acceleration every time.

My Image is a Tile for a Game its isometric ( its a floor tile ) and some parts are transparent, my application is a tile editor and draws a white rect first and paints then the image over it, otherweise i wouldnt recognize the wrong position (9,9) instead of (11,11)

#4

i forgot this is my drawing code


    /**********************************************************************************************
     * Create peer
     *********************************************************************************************/
    public void addNotify()
    {
        super.addNotify();

        setBackground(SystemColor.control);

        Insets insets = getParent().getInsets();
        setLocation(insets.left, insets.top);
        setSize(10, 10);
    }

    /**********************************************************************************************
     * paint
     *********************************************************************************************/
    public void paint(Graphics g)
    {
        super.paint(g);

        int xpos = 10;
        int ypos = 10;

        for ( int idx=0; idx<TerrainItem.itsItemList.size(); idx++)
        {
            g.setColor(Color.white);
            g.fillRect(xpos+1, ypos+1, TerrainItem.width, TerrainItem.height);
            g.setColor(Color.black);
            g.drawRect(xpos, ypos, TerrainItem.width+1, TerrainItem.height+1);

            TerrainItem aItem = (TerrainItem)TerrainItem.itsItemList.elementAt(idx);
            if ( null != aItem )
            {
                if ( null != aItem.itsImage )
                {
                    g.drawImage(aItem.itsImage, xpos+1, ypos+1, null);
                }
            }

            xpos += TerrainItem.width + 4;
            break;
        }

        // Hack - this copies Images to VRAM
        if ( 10 == getSize().width )
        {
            setSize(50, 50);
        }
        else if ( 50 == getSize().width )
        {
            setSize(100, 100);
        }
        else if ( 100 == getSize().width )
        {
            Insets insets = getParent().getInsets();
            setSize(getParent().getSize().width - insets.left - insets.right, getParent().getSize().height - insets.top - insets.bottom);        
        }
    }
#5

I doubt that this causes your problems, but just in case:
First, why did you need that fiddling with insets and sizes?

Also, never use addNotify. There’s no need for it, and it’s documented that you shouldn’t call or override it.

What problem were you solving with this?

We might chose not to use accelerated copy of the image in some cases (like weird clipping, for example). That’s what could be happening.

The thing with the image going like
not accelerated -> accelerated -> not accelerated -> accelerated -> accelerated ->**
is most likely due to a bug we’ve recently fixed (1.4.1_02, 1.4.2).