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?
[Message sent by forum member 'dolda2000' (dolda2000)]

http://forums.java.net/jive/thread.jspa?messageID=258745

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to