does Java2D support transparency for images?

Java 2D
#1

I tried with png’s but instead of transparent it turned up black :(.

#2

yes it does.

Most likely, you are creating the image incorrectly.

What paint program are you using?

#3

GIMP and it’s transparent in there

#4

ok, how are you loading and drawing it?

#5

I use GIMP all the time to create transparent PNGs for use in my Java 2 programs… Works perfectly. I’ve never had a problem with it.

#6

here’s how i create my images and transparency works


...
new BufferedImage(loadedImage.getWidth(null), loadedImage.getHeight(null), BufferedImage.TYPE_INT_ARGB);
...
#7

Thanks, I feel so stupid now. I just forgot the A in ARGB ;D.

#8

:slight_smile:

#9

Note that to make the transparent image a “managed image” (sometimes called “automatic image”, but “managed” is a more correct and descriptive term…) you currently need to use other API than creating a BufferedImage explicitly.

That is:
new BufferedImage(…)
will give you just a palin-old BufferedImage, no possibility of acceleration under the hood. But:
GraphicsConfiguration.createCompatibleImage(…)
will give you a BufferedImage that we may, depending on various constraints, cache in VRAM and accelerate using the graphics hardware.

Of course, this currently only works for transparent (vs. translucent) images, unless you are using the not-quite-ready-for-prime-time translucency acceleration described by trembovetski in one of these forums.

In some future release, we hope to “manage” all images, no matter how they are created. But currently, we just hook into specific API calls, such as:
Component.createImage()
GraphicsConfig.createCompatibleImage()
Toolkit.getImage()
new ImageIcon().getImage()

Chet
Java2D

#10

yep he’s, of course, right.

this extremely long line of code might be better:

GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration().createCompatibleImage(loadedImage.getWidth(null), loadedImage.getHeight(null), Transparency.BITMASK);
#11

btw, it might not be so good after all :slight_smile:

i get a not so cool java.lang.OutOfMemoryError when loading ~250 images (sprites, backgrounds, etc)

#12

ahem, i was a bit hasty there hehe

i had written createCompatibleVolatileImage() instead of createCompatibleImage() and thus forcing all of them into vram

#13

I would think that you would get this same error whether you were creating the BufferedImages explicitly (new BufferedImage) or as managed images (createCompatibleImage()); we are essentially doing the same type of thing underneath. In the managed image case, we may also create a VRAM-cached version of the image, but these cached images do not affect the size of the Java heap.

In any case, if you are having heap-size problems, you might want to increase your heap size when you run Java. It runs with a default heap size of 64 M on Windows (I believe); maybe try something like:
java -Xmx128m
or try other values until you get one that works for you.
Also, if you know your heap will grow to that size, then you probably also want to increase the initial heap size to eliminate the performance penalty of the VM growing the heap incrementally:
java -Xms128m
would start off Java with a heap of 128 megs (I think it starts at 16M by default, but I’m hazy on that detail).

Chet.

#14

the error only occured with createCompatibleVolatileImage()

#15 
new ImageIcon().getImage()

lazy! evil!

resist the temptation of the darkside!

#16

[quote]yep he’s, of course, right.

this extremely long line of code might be better:

GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration().createCompatibleImage(loadedImage.getWidth(null), loadedImage.getHeight(null), Transparency.BITMASK);

[/quote]
alternatively, (and alot shorter :P)


<someComponent>.getGraphicsConfiguration().createCompatibleImage(width,height,Transparency.BITMASK);
#17

the component has to be visible, right?

#18

depends what the component is.

Component.getGraphicsConfiguration() says it does this…

where as Window does this…

from what i’ve found, I don’t think a Window has to be visible for it to have a GraphicsConfiguration object associated with it.

#19

it just seems silly to create a Frame object just for the sake of loading an image in a library of convenient methods :slight_smile:

#20

That wasn’t what i was suggesting, you will ordinarily have a Frame onto which you will render your images anyway.

  1. create your game Frame.
  2. load your images (using either frame.getToolkit().createImage(), or ImageIO.read()
  3. copy your loaded images onto acceleratable images (frame.getGraphicsConfiguration().createCompatibleImage() or frame.getGraphicsConfiguration().createcompatibleVolatileImage())

having steps 2) & 3) is wasteful, and hopefully will be combined in 1.4.2 or 1.5.

p.s. I know frame.createImage() returns an acceleratable image, but I prefer not to use this method, as it is asynchronous, messy, and the images returned have an underlying ImageProducer that misbehaves with some of the image manipulation classes.