The layer does not cache any presentation by itself. This should be used if the layer is cached by some other layer, like a TileLayer or BitmapLayer, or for surface layers in a GlobeView.

This mode is specifically designed to cache the presentation of application data stored in MemoryDataSet and CustomDataSetProxy instances. It provides efficient caching just like a TileLayer, but it also allows the application to modify individual features in the datasets without discarding the entire cache.

This mode will typically give a much better performance compared to an uncached layer. It does have a number of limitations though:

• The only types of datasets allowed in the layer are MemoryDataSet and custom datasets supporting dynamic caching. In a few cases with operators with multiple inputs, other datasets may be used, see the Remarks section below.

• SplitOperator instances may be used in the layer, but they will not cache their input features for reuse, as they would normally do.

• If the features are modified in the operator chain, the new features must retain the same feature IDs as the original features; this is how most Carmenta Engine operators work. But there are some operators that merge several input features into one output feature; since these operators cannot retain the original feature IDs, they do not support dynamic cache, with a single exception: the AirspaceCoverageOperator.

• The order of the features must not be changed in the operator chain (i.e SortOperator or similar custom operators may not be used).

• Operators that generate features without a dataset, like GridGenerator, are not supported.

Similar to Dynamic, but the cache is updated asynchronously on a dedicated background thread. When the layer is updated on the GUI thread, it will only render the objects currently in the cache, and will not process any features from the input operator.

The upside of this is that the GUI thread will do less work, resulting in a higher and steadier frame rate, and maybe improve the responsiveness of the application UI. The downside is that modifications to the features may not be reflected on screen directly, it may take a few frames until the changes are visible.

The background thread will wake up and update the cache each time the view parameters are changed, or when features in a MemoryDataSet or custom dataset have been updated and the dataset lock is released. When the cache has been updated, the layer will also request the view to perform an update. So with this cache mode, you don't need to update the view explicitly when you've updated your features.

The layer does not cache any presentation by itself. This should be used if the layer is cached by some other layer, like a TileLayer or BitmapLayer, or for surface layers in a GlobeView.

This mode is specifically designed to cache the presentation of application data stored in MemoryDataSet and CustomDataSetProxy instances. It provides efficient caching just like a TileLayer, but it also allows the application to modify individual features in the datasets without discarding the entire cache.

This mode will typically give a much better performance compared to an uncached layer. It does have a number of limitations though:

• The only types of datasets allowed in the layer are MemoryDataSet and custom datasets supporting dynamic caching. In a few cases with operators with multiple inputs, other datasets may be used, see the Remarks section below.

• SplitOperator instances may be used in the layer, but they will not cache their input features for reuse, as they would normally do.

• If the features are modified in the operator chain, the new features must retain the same feature IDs as the original features; this is how most Carmenta Engine operators work. But there are some operators that merge several input features into one output feature; since these operators cannot retain the original feature IDs, they do not support dynamic cache, with a single exception: the AirspaceCoverageOperator.

• The order of the features must not be changed in the operator chain (i.e SortOperator or similar custom operators may not be used).

• Operators that generate features without a dataset, like GridGenerator, are not supported.

Similar to OrdinaryLayerCacheModeDynamic, but the cache is updated asynchronously on a dedicated background thread. When the layer is updated on the GUI thread, it will only render the objects currently in the cache, and will not process any features from the input operator.

The upside of this is that the GUI thread will do less work, resulting in a higher and steadier frame rate, and maybe improve the responsiveness of the application UI. The downside is that modifications to the features may not be reflected on screen directly, it may take a few frames until the changes are visible.

The background thread will wake up and update the cache each time the view parameters are changed, or when features in a MemoryDataSet or custom dataset have been updated and the dataset lock is released. When the cache has been updated, the layer will also request the view to perform an update. So with this cache mode, you don't need to update the view explicitly when you've updated your features.

The layer does not cache any presentation by itself. This should be used if the layer is cached by some other layer, like a TileLayer or BitmapLayer, or for surface layers in a GlobeView.

This mode is specifically designed to cache the presentation of application data stored in MemoryDataSet and CustomDataSetProxy instances. It provides efficient caching just like a TileLayer, but it also allows the application to modify individual features in the datasets without discarding the entire cache.

This mode will typically give a much better performance compared to an uncached layer. It does have a number of limitations though:

• The only types of datasets allowed in the layer are MemoryDataSet and custom datasets supporting dynamic caching. In a few cases with operators with multiple inputs, other datasets may be used, see the Remarks section below.

• SplitOperator instances may be used in the layer, but they will not cache their input features for reuse, as they would normally do.

• If the features are modified in the operator chain, the new features must retain the same feature IDs as the original features; this is how most Carmenta Engine operators work. But there are some operators that merge several input features into one output feature; since these operators cannot retain the original feature IDs, they do not support dynamic cache, with a single exception: the AirspaceCoverageOperator.

• The order of the features must not be changed in the operator chain (i.e SortOperator or similar custom operators may not be used).

• Operators that generate features without a dataset, like GridGenerator, are not supported.

Similar to DYNAMIC, but the cache is updated asynchronously on a dedicated background thread. When the layer is updated on the GUI thread, it will only render the objects currently in the cache, and will not process any features from the input operator.

The upside of this is that the GUI thread will do less work, resulting in a higher and steadier frame rate, and maybe improve the responsiveness of the application UI. The downside is that modifications to the features may not be reflected on screen directly, it may take a few frames until the changes are visible.

The background thread will wake up and update the cache each time the view parameters are changed, or when features in a MemoryDataSet or custom dataset have been updated and the dataset lock is released. When the cache has been updated, the layer will also request the view to perform an update. So with this cache mode, you don't need to update the view explicitly when you've updated your features.

The layer does not cache any presentation by itself. This should be used if the layer is cached by some other layer, like a TileLayer or BitmapLayer, or for surface layers in a GlobeView.

This mode is specifically designed to cache the presentation of application data stored in MemoryDataSet and CustomDataSetProxy instances. It provides efficient caching just like a TileLayer, but it also allows the application to modify individual features in the datasets without discarding the entire cache.

This mode will typically give a much better performance compared to an uncached layer. It does have a number of limitations though:

• The only types of datasets allowed in the layer are MemoryDataSet and custom datasets supporting dynamic caching. In a few cases with operators with multiple inputs, other datasets may be used, see the Remarks section below.

• SplitOperator instances may be used in the layer, but they will not cache their input features for reuse, as they would normally do.

• If the features are modified in the operator chain, the new features must retain the same feature IDs as the original features; this is how most Carmenta Engine operators work. But there are some operators that merge several input features into one output feature; since these operators cannot retain the original feature IDs, they do not support dynamic cache, with a single exception: the AirspaceCoverageOperator.

• The order of the features must not be changed in the operator chain (i.e SortOperator or similar custom operators may not be used).

• Operators that generate features without a dataset, like GridGenerator, are not supported.

Similar to OrdinaryLayerCacheMode.Dynamic, but the cache is updated asynchronously on a dedicated background thread. When the layer is updated on the GUI thread, it will only render the objects currently in the cache, and will not process any features from the input operator.

The upside of this is that the GUI thread will do less work, resulting in a higher and steadier frame rate, and maybe improve the responsiveness of the application UI. The downside is that modifications to the features may not be reflected on screen directly, it may take a few frames until the changes are visible.

The background thread will wake up and update the cache each time the view parameters are changed, or when features in a MemoryDataSet or custom dataset have been updated and the dataset lock is released. When the cache has been updated, the layer will also request the view to perform an update. So with this cache mode, you don't need to update the view explicitly when you've updated your features.