Most graphics APIs are state-based. The program sets up drawing state in the display manager that defines the colour, font, translation, fill texture, etc. used by drawing operations. This reduces the amount of data that needs to be passed across the kernel boundary or network for each drawing operation.
How do you make Structured Graphics composable?
If you are writing a graphics program that uses Structured Graphics, you may want to define a composite shape and then draw it in different places on the display, at a different size, rotated or in a different colour.
Therefore:
Each Structured Graphics object should encapsulate a modification to the drawing state held in the display manager, such as the Single Transform. Composing graphical objects will cause the child to inherit the drawing state created by its tree of containers.
Define the visual objects using a Directed Acyclic Graph (DAG) in which the leaves represent primitive shapes and intermediate nodes either encapsulate a small, reversible change to the state of the display manager that is applied to a single subgraph or compose multiple subgraphs.
Drawing is performed by walking over the graph in depth-first order, performing the following operations on the various types of nodes:
Intermediate Nodes:
apply the state change to the display manager, draw the subgraph, then reverse the state change in the display manager.
Composite Nodes:
draw each of their subgraphs in turn. Advanced systems can implement other composition operators, such as constructive area (or solid) geometry (CAG or CSG).
Leaf Nodes:
draw a primitive shape. The drawing will be affected by all the state changes applied to the display manager while traversing the graph.
A shape can be drawn multiple times, with different transformations and other properties, by defining it once and then linking it into different parts of the graph so that different transformations are applied to it each time it is visited during the graph traversal.
However, compared to a simple Structured Graphics framework, it is harder to map from the leaves of a Scene Graph to areas of the display, because arbitrary transformations can be applied to the shapes at the leaves of the graph. These calculations are required to calculate minimim Refresh Rectangles or to implement interactivity. Such mappings must be performed by walking over the graph, keeping track of transformations by performing the matrix multiplications in the visitor. Even though this is computationally more expensive than algorithms required by a simple Structured Graphics framework, it can still reduce the drawing time significantly when used to calculate minimum Refresh Rectangles.
A Scene Graph is often used as a high-level interface for assembling Compiled Graphic Commands.
A Render Graph is an optimisation of the Scene Graph model.
This pattern is widely used in toolkits for 3D graphics. In particular, OpenInventor, Open Scene Graph and Java3D all use Scene Graphs to structure scenes. It is less widely used in 2D graphics. Examples include the Morphic Interface framework in the Self Language and Squeak Smalltalk, the Scene Beans and Jazz toolkits for Java, the Gnome Canvas display widget, and the SVG graphics file format defined by the W3C.
See original on c2.com 