DD::Image::TopDownGraphEvaluator Class Reference

Public Member Functions
	TopDownGraphEvaluator ()
	Create a TopDownGraphEvaluator.
void	execute (Op *op)
	Execute the graph from a terminal op.

Static Public Member Functions
static void	Execute (Op *op)
	Create a TopDownGraphEvaluator and use it to execute the graph from a terminal op.
static bool	Enabled ()
	Query if TopDown rendering is enabled.
static void	Enable ()
	Enable TopDown rendering.
static void	Disable ()
	Disable TopDown rendering.
static void	EnableDebugging ()
	Enable Top-down debugging output.
static bool	DebuggingEnabled ()
	Query if Top-down debugging output is enabled.
static void	DisablePrioritizedRendering ()
	Disable Top-down prioritized rendering.
static bool	PrioritizedRenderingEnabled ()
	Query if Top-down prioritized rendering is enabled.

Detailed Description

A class to evaluate an op graph in top-down order.

Note that "evaluation" currently refers to rendering but the more general term has been used to allow for support of other forms of evaluation in the future.

The default behaviour is to fully evaluate ops before executing any downstream ops that depend on their output. This is to support the general case where ops may need to sample randomly from inputs or require the entire input to be available before computation can begin. Ops that are connected to multiple downstream ops will be run as separate tasks (in parallel where possible) and their outputs cached (if supported) to avoid having to recompute them each time they are fetched. Ops can override the opHints() method to provide more information to the top-down system to override the default behaviour and improve overall performance (see OpHints.h for more details).

Ops that are connected to only a single output may benefit from being chained together within a single task to avoid unnecessary caching and reduce scheduling overhead, which can lead to improved performance.

Not all ops need to wait for their inputs to be fully computed. The most notable example being PixelIops, which have a 1:1 correspondence between their input and output pixels and don't care about the evaluation order of these pixels. For these cases the top-down system is able to split the work up into smaller tasks and use multiple threads to evaluate the op in parallel. This is currently only supported for scanline ops but other op classes (for example, RIPOps) may have their own internal multithreading. In such cases it is recommended that they specify the eInternalMultithreaded op hint to ensure the top-down system takes this into account by giving these ops as many worker threads as it can.

The system currently only supports image ops derived from the Iop class. All other ops will be ignored and left to the bottom-up renderer to evaluate lazily when downstream ops attempt to fetch their output.