Alpha shapes are slow.

Java 2D
#1

Drawing semi-transparent shapes with an alpha comonent is SLOW SLOW SLOW.

I really can’t understand where the bottle-neck is now. I’m drawing semi-transparent shapes (About 20 every frame), and my frame-rate is suffering horribly due to it. I’m getting around 9 FPS, and without the shapes being drawn at least 29-32 FPS (Which is what I’m shooting for). Any suggestions?

-Jason Thomas.

#2

Of course they are slow!! Transparency is extremely hard to accomplish if not supported by hardware.

So if you really need it, head for using a 3D accelerator.

Ahm, or try doing it yourself! Would need to specialized and easy to handle color format (indexed, or 24bit RGB?), specialize on certain transparency levels and then write pixel-setting routines. This will enligthen you how difficult it can be doing it fast.

#3

also, if your drawing onto a VolatileImage (that includes BufferStrategy rendering) performance will absolutely die.

if you have to use an AlphaChannel (or AlphaCompositing), make sure all your images are in main memory. (not vram)

#4

Ugh… So it doesn’t just use a BITMASK in the background? I mean… You’d think it would just draw every other pixel in it’s routine, rather than actually drawing transparent pixels. Also, is using a BufferedImage risky? I know as a fact often these Images will be implemented as an “Automatic Image”, meaning sometimes it may be using a VolatileImage in the background. Perhaps I should just use a regular image.

-Jason Thomas.

#5

I found out that the best way of doing this was making gifs manually transparent in the file.

Just draw every other pixel transparent, but this only work on reasonably high resolutions AND the hardware acceleration(?) disappears if you turn it into bufferedImage, or at least did for me in certain areas. Yes it is frustrating, but at least you have an option.

#6

IMHO automatic images are the best solution
( graphicsConfiguration.createImage(width,height,[Transparency.OPAQUE|Transparency.BITMASK]) )

here are my reasons…

  1. automatic images are almost as fast as VolatileImages (ive benchmarked the 2, the difference realy is negligable)

  2. automatic images support bitmask transparency (impossible with VolatileImage in the current 1.4.1_01 api)

  3. automatic images handle the loss of their vram surface automatically, hence, less code.

  4. if you draw an automatic image and perform a software operation (such as AlphaCompositing) the version of the automatic image in main memory is used.
    If you do the same with a VolatileImage, the performane hit is very dramatic (the image has to fetched from vram, the operation performed, and the image copied back to vram)

i’ve got a little app. that demonstrates these issues.

http://www.pkl.net/~rsc/Balls.jar

its got all sorts of options, 1 of the most interesting, is this :-

set the imageType to VolatileImage
the buffering mechanism to BufferStrategy
and turn on AlphaCompositing

then, compare it to the speed of this :-

imageType automatic image (masked or unmasked)
buffer strategy to Normal
AlphaCompositing on as well

IMHO, VolatileImage should be ditched from the API, and hardware acceleration should be done behind the scenes.
In its current state VolatileImage is useless, and until all pixel operations have hardware support enabled, it always will be.

abu,