The content on demand feature operates at
the granularity of SDM model objects. Content on demand makes use
of the following concepts.
Content controller
The content controller maintains a state
for each model object. A model object can be in one of three
states:
- locked The object content is loaded and in use.
- loaded The object content is loaded, but not locked. It is considered as cached and will be unloaded when the cache is full.
- unloaded The object content is not loaded.
The state changes after events, such as a
user request, a zoom or a pan change (in fact visible area
changes), have taken place. The controller then sends a
notification to explicitly load or unload a set of objects.
Usually, the lifecycle of an object content is: unloaded, then locked,
then loaded, then potentially back to unloaded.
The cache is virtual. The object content is held in the SDM
model. When the state changes to loaded,
this simply means that the content remains in the model. As a
matter of fact, the SDM model implements the cache for the object
content, and the controller manages this cache.
The controller contains the states of the
objects as well as a handler that processes the load and unload
commands.
Cache size tuning
Extreme values for the cache size have a
radical impact on the content on demand behavior.
- Null (0) cache size: The objects are either in use (locked) or unloaded. Use this value to minimize the memory footprint.
- Infinite cache size: The objects are loaded when needed but never unloaded. This is a pure lazy load behavior.
For other cache size values, the objects
are loaded when locked and remain in the cache until they are
flushed (FIFO way) to keep the average memory size close to
constant. Note that when objects are requested to be locked, they
are loaded before the cache is purged to avoid unloading an
object that is going to be locked again. This means that the
cache can temporarily be larger that the expected size.
Locking requests
A locking request is an event sent to the
controller to lock, load or unload objects. There are two types
of event:
- Area events The controller is requested to lock all objects that intersect a given area. A mode indicates whether previously locked objects should remain locked or should be unlocked, that is, loaded (default). Typically, the area may be computed from the visible part of the main view in order to load all visible objects.
- Set events The user sends a request to the controller to lock, load, or unload a given set of objects. For example, a drill-down mechanism loads the content of the selected object.
Both types of event are non exclusive: An
area event may be followed by a set event, and conversely.
Notifications
The controller does not know by itself how to load the content of
SDM model objects. On request, it calls a handler, IlvContentHandler, that performs the load
and unload actions by upgrading the SDM model. Then, the usual
SDM model notifications take over to customize and refresh the
graphic representations.
A load event is sent when the object state
changes from unloaded to locked or loaded.
An unload event is sent when the object
state changes from locked or loaded to unloaded.
No notification is sent when the state
changes between loaded and locked.
Multithreading
The handler is able to work
asynchronously, that is, if the controller asks to load an
object, the handler marks the object as locked while the object
may be loaded in a separate thread. In any case, the handler
must notify the SDM model when the action is complete. The
locking requests are synchronized, so that the handler holds
the controller synchronization lock until completion of the
event.
SDM model changes
The controller is aware of SDM model
structural changes when:
IlvSDMEngine.setModel()sets a new model: All the objects are unloaded without notification to the handler.- The SDM model deletes an object: The object is unloaded in the controller without notification to the handler.
To summarize, the controller forgets about
the obsolete objects of the model.