The IlvRasterMappedBuffer class

The IlvRasterMappedBuffer class manages raster data for readers. It uses temporary files to store the data when it is not needed.
The buffer stores a table of [width x height] pixel values. Pixel values can use different primitive types, such as byte , short or integer values. The pixel value type must be compatible with the color model of the associated IlvRasterProperties object. The buffer is backed up by two mechanism to reduce memory consumption:
  • Memory mapped temporary files: image data is saved in a temporary file that is then mapped in memory (as in the case of the java.nio.MappedByteBuffer class), giving access times close to those of direct memory storage.
  • Random access files: image data is saved in a temporary file. When a pixel value needs to be read, it is accessed through a java.io.RandomAccessFile.
If machine dependant constraints prevent the memory mapped mechanism from succeeding (on 32 bits machines, for example, this happens when more than 2-4GB of images have been loaded), the random access file mechanism is put in place immediately.
The IlvRasterTemporaryFileManager class handles temporary files. The temporary file folder can become cluttered, for example, after an application has been interrupted brutally by errors, exceptions, or even debugging session stops. To clean the temporary file folder, you can call:
IlvRasterTemporaryFileManager.removeAllFiles();
This call searches for all temporary files created by JViews Maps applications and try to remove them. Temporary files that are in use, for example, if another application is running, are not removed.
Note
When using the IlvRasterMappedBuffer class in unsigned applets, the creation of temporary files is forbidden. Before loading the data into the model (usually through an addMap call), the application must change the memory policy management to avoid the creation of temporary files. This is done using:
IlvRasterMappedBuffer.setDefaultMemoryPolicy(IlvRasterMappedBuffer.
USE_MEMORY);
With this call, all operations use direct memory to store pixel data. An alternative solution is to sign the applet to allow temporary file creation.
You can even improve this mechanism by providing a Just In Time (JIT) loader. Instead of loading and filling the image bytes at creation, you can provide an instance of JITLoader , that loads the image bytes only when the image is about to be displayed. For example:
IlvRasterMappedBuffer.JITDataLoader jitLoader = new
   IlvRasterMappedBuffer.JITDataLoader() {
      public void loadData(IlvRasterMappedBuffer source, IlvRasterProperties
          properties) {
             System.out.println("loading "+properties.getBaseName());
             // load the data...
          }
      public void unloadData(IlvRasterMappedBuffer source,
         IlvRasterProperties properties) {
         // raz the stored bytes.
      source.setBytes(new byte[0]);
      }
   };
source.setLoader(jitLoader);
If your memory policy is USE_MAP , and you use a JIT loader (or a raster format that internally uses one, such as GeoTIFF, DTED® or CADRG), you should be aware that the loading will first happen in memory. To save load time, the creation of the disk-mapped memory will happen in a background thread. This means that the memory necessary to store the image pixels will be kept for some time in the JVM™ , until the disk map is ready to use. In some cases, for example when your application loads lots of large images at the same time, this can lead to out of memory errors, which are by default ignored (the image load restarts again after some time). See also callJITLoaderIfNecessary and setLoadRetryingOnOutOfMemory for more control on this.