Killer Game Programming in Java

VolatileImage

Whereas managed images are created by the JVM, the VolatileImage class allow programmers to create and manage their own hardware-accelerated images. In fact, a VolatileImage object exists only in VRAM; it has no system memory copy at all (see Figure 5-7).

Figure 5-7. A VolatileImage object

VolatileImage objects stay in VRAM, so they get the benefits of hardware blitting all the time. Well, that's sort of true, but it depends on the underlying OS. In Windows, VolatileImage is implemented using DirectDraw, which manages the image in video memory, and may decide to grab the memory back to give to another task, such as a screensaver or new foreground process. This means that the programmer must keep checking his VolatileImage objects to see if they're still around. If a VolatileImage's memory is lost, then the programmer has to re-create the object. The situation is better on Linux/Solaris since VolatileImage is implemented with OpenGL pbuffers, which can't be deallocated by the OS.

Another drawback with VolatileImages is that any processing of an image must be done in VRAM, which is generally slower to do as a software operation than similar calculations in RAM. Of course, if the manipulation (e.g., applying an affine transform such as a rotation) can be done by the VRAM hardware, then it will be faster than in system memory. Unfortunately, the mix of software/hardware-based ...