Alpha blending performance
I'm having some serious trouble with the performance of alpha blending in Java -- so serious that I suspect that I'm doing something wrong. I don't know what I'm doing wrong, though, so I'm hoping someone might be able to tell me. Here follows the results of some experiments I've been doing.
First of all, I'm trying to draw BufferedImages with an alpha channel directly onto a window. I'm using Java 1.6 all the time. I'm trying to draw a number of 50x50 images onto the window at 16 FPS, and performance seems to scale linearly with around 6% CPU per images (so at 4 images, it consumes ~24% CPU, at 8 images ~50% CPU, and at around 15 or more images the framerate starts to drop). I also tried to draw one 800x600 image onto a window, and it takes around 400 ms. Performance in this test seems to be about the same on both Linux and Windows, by the way.
Second, I'm trying to use VolatileImages to draw the images onto the window (using GraphicsConfiguration.createCompatibleVolatileImage()). However, that doesn't work at all, because Java2D will only give me opaque VolatileImages. It doesn't return VolatileImages with either 1-bit or alpha transparency, on either Linux or Windows. It may be worth mentioning that I have direct rendering working on the Linux system.
Third, I tried to use the Direct3D rendering pipeline by setting sun.java2d.d3d=true. That actually works fairly well, and I seem to be able to draw alpha transparent images at about the same rate as normal images, and opaque images are drawn faster as well. However, it obviously only works on Windows, so I'd very much prefer not use it. A weird thing I noticed is that I still don't get accelerated VolatileImages for translucent images. Should it be like that?
Fourth, I tried to use the OpenGL rendering pipeline by setting sun.java2d.opengl=true, which is a very mixed blessing. because performance became definitely wonderful on Windows. All draw operations dropped to hardly measurable times. However, it doesn't seem to work at all on Linux, because performance wasn't affected at atll, and when setting sun.java2d.trace=count, it indicates that it's still using the normal XPM drawing routines. There also seems to be a fairly serious bug when using it on Windows, because when drawing newly created BufferedImages, the result is some weird monochrome blue drawing. As long as the BufferedImages weren't created recently, they are drawn as they should. Am I doing something weird to cause this behavior? Oh, and by the way, I'm still not getting accelerated VolatileImages, which I find weird.
Also, I'm wondering about the usage of the alternate pipelines as such. It seems to be working fairly OK for stand-alone programs, but what about applets? Is it at all possible to use the alternate pipelines when writing an applet? Even if I can somehow get permission to change system properties within an applet, AWT has already been started and set up its pipelines by that time, right?