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.