Page Comparison

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

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:

Not Doing