-
Notifications
You must be signed in to change notification settings - Fork 169
Description
The current layout alrogithm is relatively simple and achieves its goal of avoiding crossings of branches and (other) streamtrees. The basic idea (implemented in calcRenderingOrder()
and setDisplayOrder()
) is, e.g.:
- given a set of 3 connected streamtrees stream
$i$ with child streams$j,k$ - Create a structure encoding each streamtrees as nodes in a (non-bifurcating) tree structure
- Order child nodes by the divergence/temporal value of where they branch off the parent, e.g.
$[j, k]$ where$j$ branches off$i$ earlier than$k$ - Post-order traversal of this structure to determine rendering order of
$[j, k, i]$ which avoids any crossings
One side effect of this is that the earliest child streams will always be positioned higher than any subsequent children. For instance in this flu example 3C.2a2 and 3C.2a3 are rendered at the top of the tree (LHS of figure), however there is a better positioning available for them (RHS):

This improvement should be achievable within calcRenderingOrder()
- while we haven't yet calculated display orders we shouldn't need these, only the span of divergence/temporal values occupied by each streamtree which is simply the streamPivots
array.
Separately, all child streamtrees ({1,1a,1a.1}
connected set of streamtrees below the parent (orange stream):

I'm less certain about how to choose when to rotate nodes, so this is more of a speculative "something to look into" topic.