Tree Layout

The yFiles tree layouter family specializes in the layout of tree-structured graphs. The need to visualize directed or undirected trees arises in many application areas, e.g.,

Tree layout is provided in a number of different styles:

In addition, the generic tree layout algorithm provides the basis for a multitude of tree layout schemes.

Advanced Layout Concepts

Sorting Child Nodes

The tree layout algorithms support sorting the child nodes in a subtree using a NodeOrderComparator in conjunction with a data provider that is registered with the graph using the look-up key NodeOrderDpKey. The following property registers custom IComparer implementations with a tree layouter. Except GenericTreeLayouter, this property is available in all tree layouters.

IComparer Comparator { get; set; }
Description IComparer registration.

Class NodeOrderComparator, when given the outgoing edges of a (sub)tree's root node, uses the target nodes of the edges for querying the data provider. The System.IComparable objects, which the comparator expects in return, are then used to determine the order of the child nodes.

Enhancing the Layout Process

Table 10.53, “Layout Stages” lists the layout stages that can be used with all tree layout algorithms to enhance the layout process.

Table 10.53. Layout Stages

Classname Description
TreeReductionStage Adds support for tree-like graphs.

Class TreeReductionStage is a layout stage that transforms graphs into proper trees. It automatically removes all non-tree edges prior to an algorithm's run and re-inserts them thereafter. When the edges are re-inserted, different routing styles can be applied.

Tutorial Demo Code

The layout module class TreeLayoutModule.cs from the LayoutModulesWindow demo application presents the setup of the tree layout algorithms in an application context.

Figure 10.62. Sample layouts produced with the tree layouters from namespace yWorks.yFiles.Layout.Tree

Directed

Class TreeLayouter is a layouter mainly used for directed trees that have a unique root element. Starting with the root node the nodes are arranged either from top to bottom, left to right, right to left, or bottom to top. The edges of a graph can either be routed as straight lines or in an orthogonal bus-like fashion.

Supplemental Layout Data

TreeLayouter knows a number of data provider keys which are used to retrieve supplemental layout data for a graph's elements. The data is bound to the graph by means of a data provider, which is registered using a given look-up key. Table 10.54, “Data provider look-up keys” lists all look-up keys for TreeLayouter.

Binding supplemental layout data to a graph is described in the section called “Providing Supplemental Layout Data”.

Table 10.54. Data provider look-up keys

Key Element Type Value Type Description
EdgeLabelLayoutDpKey edge LabelLayoutData[] For each edge an array of LabelLayoutData objects that encode size and preferred placement for all labels of the edge.
NodeLabelLayoutDpKey node LabelLayoutData[] For each node an array of LabelLayoutData objects that encode size and preferred placement for all labels of the node.
NodeHaloDpKey node NodeHalo A NodeHalo object that specifies the halo sizes at each side of a node.

Layout Options

These options configure class TreeLayouter in detail.

Minimal Layer Distance
API
double MinimalLayerDistance { get; set; }
Description Determines the minimal distance between parent and child nodes.
Minimal Node Distance
API
double MinimalNodeDistance { get; set; }
Description Determines the minimal distance between the siblings of a node.
Layout Orientation
API
LayoutOrientation LayoutOrientation { get; set; }
Description

Determines the main layout orientation, i.e., the overall orientation for the edges in a layout. This property is inherited from CanonicMultiStageLayouter, the direct superclass of TreeLayouter. The layout algorithm tries to arrange nodes in such a way that all edges point in the main layout direction.

By default, the overall orientation for the edges will be from top to bottom. The other three layout directions can be set using the constants from the LayoutOrientation enumeration. Example 10.30, “Setting the layout orientation” shows how to set the layout direction.

Note

The documentation for the other layout options assumes that this default orientation is being used.

Example 10.30. Setting the layout orientation

TreeLayouter tl = new TreeLayouter();
// Use left-to-right main layout direction.
tl.LayoutOrientation = LayoutOrientation.LeftToRight;
Port Style
API
PortStyle PortStyle { get; set; }
Description

Determines the port assignment policy to be used. Ports can be placed

  • at the center of the corresponding nodes,
  • in the middle of the border, or
  • distributed along the border of the corresponding nodes.

Policies can be set using the constants from the PortStyle enumeration.

Edge Routing Style
API
EdgeLayoutStyle LayoutStyle { get; set; }
Description If set, all edges will be routed orthogonally in a bus-like fashion. If not set, the edges will be routed as straight-line segments.
Bus Alignment
API
double BusAlignment { get; set; }
Description Determines vertical bus alignment within the space between two layers for edges from a given (root) node to its children that are routed in an orthogonal bus-like fashion.
Vertical Alignment
API
double VerticalAlignment { get; set; }
Description

Specifies vertical alignment of nodes that are in the same layer. The value for the vertical alignment is interpreted relative to a layer's height, which is determined by the maximum of the node heights.

A value of 0.0 means top alignment, 1.0 means bottom alignment. The default value is 0.5, which means center alignment of all nodes in the same layer.

Child Placement Policy
API
ChildPlacementPolicy ChildPlacementPolicy { get; set; }
Description

Determines the placement of child nodes in a given tree. Depending on the actual child placement policy, an optimal area utilization can be achieved. The following policies are supported:

  • SiblingsOnSameLayer Configures the algorithm to place leaf nodes that have the same parent node in the same layer. This option is useful in order to make a graph vertically more compact.
  • AllLeavesOnSameLayer This setting results in a Dendrogram-like style and places all leaf nodes of the tree in the bottommost layer of the layout.
  • LeavesStackedLeft Configures the algorithm for a stacked style of leaf nodes consisting of a single "stack."
  • LeavesStackedRight Configures the algorithm for a stacked style of leaf nodes consisting of a single "stack."
  • LeavesStackedLeftAndRight Configures the algorithm for a stacked style of leaf nodes consisting of two "stacks."
  • LeavesStacked Configures the algorithm for a stacked style of leaf nodes that aims to balance "stack" heights. For each subtree, the algorithm decides about the actual policy depending on the number of leaf nodes: either child placement policy LeavesStackedRight or LeavesStackedLeftAndRight is used.

In the above context, "stacked" means that leaf nodes at the same parent node are placed non-overlapping below their parent node in a row that extends downwards. This allows to make a graph horizontally more compact. "Left" and "right" indicate where, relative to the center of the parent node, the row is placed.

Note that the "stacked" policies only have an effect on subtrees where all children are leaf nodes.

Global Layering
API
bool EnforceGlobalLayering { get; set; }
Description If set, the algorithm ensures that large nodes never span more than their layer. Otherwise, a more compact layout can be achieved when large nodes span two or more layers. This setting is useful, if the hierarchical structure of the tree should be more emphasized. Note that when disabled, the value set for the Vertical Alignment of nodes within their layer is ignored.

Advanced Layout Concepts

Node Halos

TreeLayouter by default supports node halos as soon as they are declared using the data provider key NodeHaloDpKey. During layout calculation, it takes any specified additional paddings around nodes into consideration and keeps the areas clear of other graph elements. The labels of a node and its adjacent edge segments are not affected and can still be placed inside or cross the node's halo.

Integrated Labeling

Besides the generic labeling support as described in the section called “Generic Labeling”, which is available with all yFiles layout algorithms, TreeLayouter additionally features integrated labeling.

Integrated labeling is available for both node labels and edge labels. They are taken into consideration when determining the positions for the nodes of the tree. With this strategy it is guaranteed that no label will overlap other objects in the diagram. Integrated labeling can be enabled or disabled using the following properties:

bool IntegratedEdgeLabeling { get; set; }
bool IntegratedNodeLabeling { get; set; }
Description Determines whether integrated labeling is enabled.

See also the section called “Integrated Labeling”.

Tip

Optimal label placement with integrated labeling can be achieved using FreeEdgeLabelModel as the label model for the edges. As explained in the section called “Label Models”, this edge label model is ideally suited in combination with integrated labeling and yields the best match for a label location that is computed by TreeLayouter.

Incremental Layout

Class TreeLayouter supports incremental layout by means of a System.Collections.IComparer implementation that provides dynamic rearrangement of all child nodes in a given subtree according to their relative coordinates. Based on this scheme, the default comparator is able to incrementally insert new child nodes at optimal positions with respect to already arranged child nodes.

The following property registers custom IComparer implementations that act globally on the entire tree:

IComparer Comparator { get; set; }
Description IComparer registration.

Alternatively, class NodeOrderComparator can be used to sort the child nodes of a subtree, too. See also the section called “Sorting Child Nodes”.

Balloon

Class BalloonLayouter is a tree layouter that positions the subtrees rooted at a node in a radial fashion around that node. It is ideally suited for huge trees (say, 10,000 nodes) since it computes fast layouts that are quite compact.

Figure 10.63. Sample layout of a tree that contains 10,000 nodes

Sample layout of a tree that contains 10,000 nodes

Supplemental Layout Data

Class BalloonLayouter knows a number of data provider keys which are used to retrieve supplemental layout data for a graph's elements. The data is bound to the graph by means of a data provider, which is registered using a given look-up key. Table 10.55, “Data provider look-up keys” lists all look-up keys for BalloonLayouter.

Binding supplemental layout data to a graph is described in the section called “Providing Supplemental Layout Data”.

Table 10.55. Data provider look-up keys

Key Element Type Value Type Description
InterleavedNodesDpKey node bool For each node a boolean value indicating whether interleaved child node placement should be enabled.
NodeHaloDpKey node NodeHalo A NodeHalo object that specifies the halo sizes at each side of a node.

Layout Options

These options configure class BalloonLayouter in detail.

Root Node Policy
API
RootNodePolicy RootNodePolicy { get; set; }
Description

Determines which node should be used as root of the tree. Available options are:

  • DirectedRoot Chooses a node with indegree zero, if present. A good choice for directed rooted trees.
  • CenterRoot Chooses the root such that the depth of the resulting tree gets minimized.
  • WeightedCenterRoot Chooses the root such that the number of paths between any two nodes that traverse the root is maximal. This seems to be a natural root for undirected trees.

Preferred Root Wedge
API
int PreferredRootWedge { get; set; }
Description This setting determines the angular range of the sector that will be reserved around the root node of the graph to accommodate the attached subtrees.
Preferred Child Wedge
API
int PreferredChildWedge { get; set; }
Description

This setting determines the angular range of the sector that will be reserved for the children of a root node. The possible angular range lies between 1 and 359. The remaining angular range (360 minus x) will be automatically used to accommodate the edge that connects to the root node.

The smaller the chosen value, the more the impression that the nodes drive away from their root nodes and the center of the graph.

Generally speaking, the compactness of the layout will decrease with smaller values. Very small values will lead to layouts that consume a lot of space.

Minimal Edge Length
API
int MinimalEdgeLength { get; set; }
Description Determines the minimal length of an edge. The smaller the chosen value the more compact the resulting layout.
Compactness Factor
API
double CompactnessFactor { get; set; }
Description This parameter influences the length of the tree edges as it is computed by the layout algorithm. The smaller the compactness factor, the shorter the tree-edges and the more compact the overall layout. The bigger the compactness factor, the more difficult, and hence slower, the layout computation.
Interleaved Child Node Placement
API
InterleavedMode InterleavedMode { get; set; }
Description

Child nodes at the same parent tree node can be placed in an interleaving fashion. Especially if some tree node has many child nodes and if they have similar sizes, the diagram can become more compact.

Available options are:

  • Off Disables interleaved child node placement for all tree nodes. This is the default setting.
  • AllNodes At each tree node child nodes will be placed interleaved.
  • SelectedNodes Enables interleaved child node placement for a custom selection of tree nodes that is given by the user. To specify the nodes, a data provider holding such supplemental layout data must be bound to the graph. The data provider is expected to be registered with the graph using key InterleavedNodesDpKey. If no data provider is registered, a simple heuristic is used to decide for which tree node the child nodes should be placed interleaved.

Figure 10.64. Effects of interleaved child node placement

Effects of interleaved child node placement
Effects of interleaved child node placement
Tree layout by BalloonLayouter... ... with interleaved child node placement enabled.

Note

If there is enough space to place the child nodes of a tree node without interleaving, they will be placed normally, even when "Interleaved Child Node Placement" is enabled.

Child Node Alignment
API
ChildAlignmentPolicy ChildAlignmentPolicy { get; set; }
Description

Determines the policy for aligning the child nodes at a tree node. Available options are:

  • AlignPlain Child nodes at the same parent tree node are aligned such that each child node has the same border-to-border distance to the parent node. When interleaved child node placement is active, two different distances will be realized.
  • AlignSameCenter Child nodes at the same parent tree node are aligned such that each child node has the same center-to-center distance to the parent node. Therefore all nodes will be placed on one common radius around their root. When interleaved child node placement is active, two different radii will be realized.
  • AlignCompact Child nodes at the same parent tree node are aligned such that the resulting drawing will be as compact as possible, not considering any symmetric constraints. This is the default setting.
  • AlignSmart Child nodes at the same parent tree node are aligned using a heuristic for a well-balanced and symmetric layout. When interleaved child node placement is active, plain alignment will be used instead of the heuristic.

Figure 10.65. Child node alignment policies

Child node alignment policies
Child node alignment policies
Child node alignment policies
Child node aligment plain... ... same center... ... compact.
Straighten Chains
API
bool ChainStraighteningMode { get; set; }
Description If activated, all nodes in a chain will be placed on a straight line. This may lead to smoother and more symmetric layouts. By default, this feature is turned off.
Allow Overlaps
API
bool AllowOverlaps { get; set; }
Description If activated, this option further increases compactness of the resulting layout, but potentially introduces slight node overlaps.
Consider Node Labels
API
bool ConsiderNodeLabels { get; set; }
Description Enables node label-aware layout calculation.

Advanced Layout Concepts

Node Halos

BalloonLayouter by default supports node halos as soon as they are declared using the data provider key NodeHaloDpKey. It considers any specified additional paddings around nodes, however, due to the straight-line routing of the edges, they can cross through these areas in the resulting diagram. Also, node halo overlaps may occur if option "Allow Overlaps" is activated.

Integrated Labeling

Besides the generic labeling support as described in the section called “Generic Labeling”, which is available with all yFiles layout algorithms, BalloonLayouter additionally features integrated labeling.

Integrated labeling is available for both node labels and edge labels. They are taken into consideration when determining the positions for the nodes of the tree. With this strategy it is guaranteed that no label will overlap other objects in the diagram. Integrated labeling can be enabled or disabled using the following properties:

bool IntegratedEdgeLabeling { get; set; }
bool IntegratedNodeLabeling { get; set; }
Description Determines whether integrated labeling is enabled.

See also the section called “Integrated Labeling”.

Enabling the integrated node labeling support of class BalloonLayouter means that each node label will be placed and arranged by BalloonLayouter such that there are no overlaps of node labels with each other or with graph elements (other than their respective node).

BalloonLayouter supports different node labeling policies that can be configured using the NodeLabelingPolicy property. The following policies are available:

Horizontal
Description Each node label will be placed at the center of its node, with horizontal orientation. Multiple node labels will be placed center aligned and stacked.
Raylike
Description Node labels of leaf nodes and node labels of nodes having exactly one successor (thus possibly forming a chain) will be oriented ray-like, i.e. with the same orientation as their node's incoming edge. Additionally, the node labels of leaf nodes will be placed outside of their node. Multiple, ray-like oriented node labels will be left aligned. Node labels of nodes having more than one successor will be placed at the center of their node, with horizontal orientation. Also, node labels that do not use a "free" label model, will be placed this way. See also below. This is the default setting.
Mixed
Description Node labels of leaf nodes will be oriented ray-like, i.e. with the same orientation as their node's incoming edge. Additionally, these node labels will be placed outside of their node. Other node labels will be placed at the center of their node, with horizontal orientation. Also, node labels that do not use a "free" label model, will be placed this way. See also below.

Note that ray-like oriented node labels are only supported by integrated labeling for node labels that use a "free" label model, e.g., FreeNodeLabelModel.

Figure 10.66. Results with different Node Labeling policies

Results with different Node Labeling policies
Results with different Node Labeling policies
Raylike Horizontal

Enabling the integrated edge labeling support of class BalloonLayouter instructs the algorithm to find optimal placements for edge labels such that there are no overlaps of edge labels with each other or with graph elements. In addition, the edge labels are also oriented and arranged by BalloonLayouter.

Figure 10.67. Edge labeling

Edge labeling
Edge label placement where labels are configured with preferred placement at the target node and on the right side of the edge.

Note that edge label placement configurations by means of the PreferredPlacementDescriptor are currently only partially supported by the integrated edge labeling of BalloonLayouter. Placement of the edge label at a specified preferred side of the edge can be guaranteed. Preferred placement of the edge label at the source node or target node, however, cannot be guaranteed entirely.

Tip

Optimal label placement with integrated edge labeling can be achieved using FreeEdgeLabelModel as the label model for the edge labels. As explained in the section called “Label Models”, this edge label model is ideally suited in combination with integrated edge labeling and yields the best match for a label location that is computed by BalloonLayouter.

Incremental Layout

BalloonLayouter can be set to "layout from sketch" mode to provide support for incremental layout. In this mode, a diagram's current drawing is taken into account when calculating a new layout. The following property enables "layout from sketch" mode:

bool FromSketchMode { get; set; }
Description Enables "layout from sketch" mode.

Horizontal/Vertical

Class HVTreeLayouter allows to layout a tree such that each subtree rooted at a node can either have a horizontal or vertical layout. For each node the layout orientation of its child nodes can be specified using the data provider look-up key SubtreeOrientationDpKey.

Supplemental Layout Data

Class HVTreeLayouter knows a number of data provider keys which are used to retrieve supplemental layout data for a graph's elements. The data is bound to the graph by means of a data provider, which is registered using a given look-up key. Table 10.56, “Data provider look-up keys” lists all look-up keys for HVTreeLayouter.

Binding supplemental layout data to a graph is described in the section called “Providing Supplemental Layout Data”.

Table 10.56. Data provider look-up keys

Key Element Type Value Type Description
SubtreeOrientationDpKey node object For each root node either HorizontalSubtree or VerticalSubtree to indicate horizontal or vertical subtree placement.

Layout Options

These options configure class HVTreeLayouter in detail.

Horizontal Space
API
double HorizontalSpace { get; set; }
Description The minimal horizontal distance between adjacent nodes.
Vertical Space
API
double VerticalSpace { get; set; }
Description The minimal vertical distance between adjacent nodes.

Class HVTreeLayouter allows to arrange subtrees either horizontally or vertically. To specify the desired placement, a data provider holding such supplemental layout data can be bound to the graph. The data provider is expected to be registered with the graph using key SubtreeOrientationDpKey. Note that in the absence of the data provider horizontal placement is chosen.

Compact

Class ARTreeLayouter generates compact orthogonal tree drawings. As a layout constraint a preferred aspect ratio (relation of width to height) can be given. This is especially useful when the graph should fit perfectly on a page of given size.

Figure 10.68. Sample layouts of the same tree using different preferred aspect ratio settings

Sample layouts of the same tree using different preferred aspect ratio settings
Sample layouts of the same tree using different preferred aspect ratio settings
Sample layouts of the same tree using different preferred aspect ratio settings
Using aspect ratio 2.0 Using aspect ratio 1.0 Using aspect ratio 0.5

Supplemental Layout Data

Class ARTreeLayouter knows a number of data provider keys which are used to retrieve supplemental layout data for a graph's elements. The data is bound to the graph by means of a data provider, which is registered using a given look-up key. Table 10.57, “Data provider look-up keys” lists all look-up keys for ARTreeLayouter.

Binding supplemental layout data to a graph is described in the section called “Providing Supplemental Layout Data”.

Table 10.57. Data provider look-up keys

Key Element Type Value Type Description
RatioDpKey node System.IConvertible For each root node a System.IConvertible object encapsulating a double value that indicates the subtree's aspect ratio.
RootPlacementDpKey node object For each root node one of PlacementTop, PlacementCorner, PlacementCornerSide, or PlacementCornerTop to indicate the root node's placement.
RoutingPolicyDpKey node object For each root node either RoutingHorizontal or RoutingVertical to indicate horizontal or vertical edge routing.

Layout Options

These options configure class ARTreeLayouter in detail.

Horizontal Space
API
double HorizontalSpace { get; set; }
Description The minimal horizontal distance between adjacent nodes.
Vertical Space
API
double VerticalSpace { get; set; }
Description The minimal vertical distance between adjacent nodes.
Bend Distance
API
double BendDistance { get; set; }
Description Determines the preferred minimal distance between each two bends of an edge and between the first and last edges and the corresponding ports.
Preferred Aspect Ratio
API
double AspectRatio { get; set; }
Description Determines the preferred aspect ratio (width by height) of the resulting layout. This option allows for creating layouts which, e.g., fit perfectly onto the page of a book.