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
then, compare it to the speed of this :-
imageType automatic image
(masked or unmasked)
buffer strategy to Normal
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.