Because the visualization pipeline carries many different types of data, and because the set of potential changes that could apply to a given type is large, a flexible hinting mechanism is necessary:
-
A hint can be a simple identifier that classifies the nature of a change, e.g: “bitmap pixels changed”, “bitmap dimensions changed”, “selection changed”, etc.
-
Or, a hint can include arbitrary amounts of metadata describing the change to varying levels of detail, e.g: a hint can provide bounding-box data, ranges of indices that changed, etc.
-
Finally, a hint can be NULL, meaning “no hint” … the receiver cannot infer anything about the nature of a change, and must “assume the worst”.
-
The hinting system must allow for any combination of “smart” nodes (nodes that alter their behavior based on hints), and “dumb” nodes (nodes that ignore hints).
-
Nodes must be able to implement sensible “fallback” behavior that produces correct results if they receive no hint, or a hint that they don’t recognize.
-
Nodes must be able to “translate” hints as they travel down the pipeline, e.g. a node that receives a “color changed” hint as an input may need to produce a “bitmap pixels changed” hint as an output, depending on how the node works.