Managed Images

Managed Images

A managed image is automatically cached in video memory (VRAM) by the JVM. When drawImage( ) is applied to its original version located in system memory (RAM), the JVM uses the VRAM cache instead, and employs a hardware copy ( blit ) to draw it to the screen. The payoff is speed since a hardware blit will be faster than a software-based copy from RAM to the screen. This idea is illustrated by Figure 5-6.

Figure 5-6. Drawing images and managed images

A managed image is not explicitly created by the programmer because there's no ManagedImage class that can be used to instantiate suitable objects. Managed images are created at the whim of the JVM, though the programmer can " encourage " the JVM to make them.

Image , ImageIcon , and BufferedImage objects qualify to become managed images if they have been created with createImage( ) , createCompatibleImage( ) , read in with getImage( ) or ImageIO 's read( ) , or created with the BufferedImage( ) constructor. Opaque images and images with BITMASK TRansparency (e.g., GIF files) can be managed. Translucent images can be managed but require property flags to be set, which vary between Windows and Linux/Solaris.

The JVM will copy an image to VRAM when it detects that the image has not been changed or edited for a significant amount of time; typically, this means when two consecutive drawImage( ) calls have used the same image. The VRAM copy will be scrapped if the original image is manipulated by an operation that is not hardware accelerated, and the next drawImage( ) will switch back to the RAM version.

Exactly which operations are hardware accelerated depends on the OS. Virtually nothing aside from image translation is accelerated in Windows; this is not due to inadequacies in DirectDraw but rather to the Java interface. The situation is a lot better on Linux/Solaris where all affine transformations, composites, and clips will be accelerated. However, these features depend on underlying OS support for a version of OpenGL that offers pbuffers . A pbuffer is a kind of off-screen rendering area, somewhat like a pixmap but with support for accelerated rendering.

Bearing in mind how the JVM deals with managed images, it is inadvisable to modify them excessively at run time since their hardware acceleration will probably be lost, at least for a short time.

In some older documentation, managed images are known as automated images .

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 operations depends on the OS.

Bearing in mind the issues surrounding VolatileImage , when is it useful? Its key benefit over managed images is that the programmer is in charge rather than the JVM. The programmer can decide when to create, update, and delete an image.

However, managed image support is becoming so good in the JVM that most programs probably do not need the complexity that VolatileImage adds to the code. ImagesTests in Chapter 6 uses only managed images, which it encourages by creating only BufferedImage s.