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.