Target release	1.0
Epic
Document status	DRAFT
Document owner	Former user (Deleted)
Designer
Developers
QA

Goals

Significantly reduce memory consumption during graph execution.
Significantly speed up graph execution by reducing tile re-computations (which may occur due to loss of cached tiles).
Let users control the sequence in which GPF requests target tiles from an Operator
Let users control the size and location of target tiles to be computed by an Operator

The latter two goals allow tile computations to depend on each other. A current tile computation shall be able to assume that spatially connected tiles have been processed before. This is a typical use case for spatial operators or operators that process scan lines from the first to the last.

Background and strategic fit

Although GPF's pull processing scheme provides numerous advantages w.r.t. streaming data processing, the use of a global common (JAI) tile cache can significantly limit its applicability. A large number of operators can consume a lot of (tile cache) memory, and adjusting the tile cache can imply tile re-computations. Both may reduce the overall processing speed.

Assumptions

All the changes will be visible to programmers only.

Requirements

#	Title	User Story	Importance	Notes
1

User interaction and design

Offer various graph executors, that give users control about how tile requests are generated in a deterministic manner.
Make sure that GPF never removes tiles from JAI tile cache that belong to a current tile request context, which comprises all tiles from a target tile to all required source tiles.
Make sure that GPF never removes tiles from JAI tile cache belonging to a tile stack in use.
Configure GPF so that it doesn't use the JAI tile cache at all. A local cache shall be used instead which is assigned to a current tile request context.

Questions

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

Question	Outcome

Not Doing