Youre right, using transparency on my buffer is useless. But regarding my sprites that need to be rotated, i think i need both of them: a BufferedImage holding the sprite image, the one loaded from file; and a VolatileImage holding the real image that is copied to my buffer. When the sprite's angle has changed, i clear the volatile and copy the Buffered applying the rotation.
Or is it better to just keep the Buffered one and apply the rotation when copying it to the buffer? I thought rotation was an heavy operation and i could skip if if uneeded by holding a copy of the rotated sprite.
If the image transform operation is hw accelerated (which it is with the opengl or d3d pipelines), image rotation is basically free as it's a simple texture mapping operation. If there's now hw acceleration then indeed it may be better to cache the rotated version. But the latter only makes sense if you make more than one copy from this cached image.
If your rotation angles are predetermined you can pre-render all rotated versions into a single sprite sheet - an image containing all possible rotations of your sprite (either at run time or at build time) and just copy the corresponding rotated version from that sprite sheet
using drawImage(src rect, dst rect) variant.
So, to summary all this up ; correct me if Im wrong :
- Drawing TO and FROM VolatileImage is accelerated.
- Drawing FROM BufferedImage is accelerated once it has been cached in VideoMemory (thats automatically done when image is copied several times)
Correct. There are cases when BI can't be cached (like if you got a hold of the data buffer, or if the image is too large, or if this type of image can't be cached - like translucent images on Linux w/o the opengl pipeline).
- BITMASK Volatile images aren't accelerated in 1.5 or 1.6.
- TRANSLUCENT Volatile images are accelerated on Windows or, using OpenGL pipeline, all platforms.
Correct. See the D3D pipeline section in 6u10 release notes for details: http://java.sun.com/javase/6/webnotes/6u10.html
- OPAQUE Volatile images have the most chances of being accelerated across platforms and jdk versions.
Yes. However, even if the image is "accelerated" it may not mean that all kinds of rendering operations are
accelerated. For example, in pre-6u10 jdk on windows only simple blits were hw accelerated (unless you
enabled the d3d pipeline with -Dsun.java2d.d3d=true), but not the transforms.
It's unfortunate that our hw-acceleration story is so complicated. =(