View Source

Target release	6.0
Epic	Link to related JIRA epic or feature
Document status
Document owner	Former user (Deleted)
Designer	Former user (Deleted)
Developers	Lead developer
QA	Lead tester

Goals

Get rid of GPF tile caching where it doesn't make sense
Allow tile-cache dedicated configurations at GPF graph node level

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.

Assumptions

List the assumptions you have such as user, technical or other business assumptions. (e.g. users will primarily access this feature from a tablet).

Requirements

#	Title	User Story	Importance	Notes
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	Additional considerations or noteworthy references (links, issues)
2	`TileCacheOp`	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

Include any mockups, diagrams or visual designs relating to these requirements.

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Question	Outcome
	Communicate the decision reached

Comments

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.

Not Doing

List the features discussed which are out of scope or might be revisited in a later release.