Java 2D Graphics Bilinear Transform Image type Frame
Java 2D Graphics image would be to put the four bits of each pixel into an 8-bit byte. In this case, the image data would actually occupy twice as much memory as given in the formula above. The following method calculates the memory usage for a BufferedImage. It retrieves the actual DataBuffer for the image and calculates the size accordingly. Note that this calculates the full size of the image’s data buffers, which is a little more realistic measure of memory usage than the minimum size given by the formula above: public static long getImageSize(BufferedImage image) { DataBuffer db = image.getRaster().getDataBuffer(); int dataType = db.getDataType(); int elementSizeInBits = DataBuffer.getDataTypeSize(dataType); return db.getNumBanks() * db.getSize() * elementSizeInBits / 8; } Managing image memory may be as simple as throwing away images that you don’t need any more.[3] Furthermore, if you have several images that represent different parts of the same data set, you should share a single DataBuffer among the images. DataBuffers really take up space, not Images. [3] Of course, you can’t actually free up the memory yourself. You have to null out references; it’s up to the garbage collector to free up the memory. 14.3.2 Double Buffering Double buffering is a technique that is described fully in Chapter 9. It’s a technique for avoiding image flickering. Basically, your application draws into an offscreen image instead of drawing directly on the screen. The image is then drawn onscreen. Double buffering doubles an application’s memory consumption. Think of it this way: instead of just needing some display memory for a window or component, your application now needs memory for a corresponding offscreen image. You should be especially worried about this if you perform double buffering for a resizeable window. Suppose, for example, that your application has a frame window with a default size of 300 by 200 pixels. An offscreen image for double buffering will be 240K, assuming you use 32 bits per pixel. Suppose the user maximizes the window, to 800 by 600 pixels. The size of the offscreen image jumps to 1.92M. But that’s not the worst of it. Many users have systems that allow for much higher screen resolutions. It’s very possible that a user could maximize your application to his or her 1600 by 1200 desktop. This makes the size of the offscreen image a whopping 7.68M! The moral of the story is to be careful about double buffering. Try to double buffer only small, size- controlled parts of your application. If you have to use double buffering on an entire window, consider making the window a fixed size, or add code to enforce a maximum size for the window. 14.3.3 Swing Components Swing components perform double buffering by default. If you use Swing components, you are already paying the memory penalty that double buffering imposes, and you should be careful about the size of these components, as discussed previously. The good news is that Swing is intelligent about its double buffering. If a component is part of a container that already has an offscreen image, the child component will paint itself into its parent’s offscreen image without creating its own offscreen image. page 271
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Java Web Hosting services