Background and strategic fit
GPF operators whose target tile rectangles exactly match source tile rectangles don’t require caching of tiles. In such cases, GPF’s tile-cache can waste a lot of memory and drastically slow down processing (Java GC, heap space swapping).
Caching of tiles should not take place automatically. Get even may get rid of the global GPF tile cache. Instead, we can introduce configurable tile-caches per operator / graph node. In addition, it may make sense to introduce a
TileCacheOp – a configurable operator, that simply puts its source tiles into a cache.
|1||Operators own tile-cache||Any tile-computing operator can have its own, configurable tile-cache. Users can configure it through graph XML or the GUI. By default, there is no tile-cache. Disposing operators after execution will definitely empty their tile-caches.||Must have|
|TileCacheOp is a configurable, source tile-pulling operator, that simply puts its source tiles into a cache. It can be used within a graph to force tile-caching at a given point.||Optional|
|3||No global tile-cache||Remove global tile-caching entirely.|
User interaction and design
Below is a list of questions to be addressed as a result of this requirements document:
If there is not a single tile-cache, how is it ensured that tile-caches do not grow too big? By giving each tile-cache it's own capacity? Or is there a central capacity administration?
It would be helpful if there were more choices on when tiles are deleted from the cache: E.g., certain image types should preferrably stay in cache, tiles should be deleted when it is certain that they have been requested for the last time, ...
Also, even if source tiles and target tiles do not match exactly, there should be a mechanism that checks when source tiles are not needed anymore. This is related to the enablement of the GPF for multisize products.