Skip to content

Stream pass

Animation demo

A look at the animation demo and what it teaches about a graph viewer's behaviour under continuous change. The picture is in motion - the viewer has to keep up without losing the reader.

A graph viewer mid-animation with nodes and edges appearing and disappearing

What the demo does

The animation demo adds nodes, removes nodes, adds edges, and removes edges, continuously. The viewer has to keep the picture readable while all of that is happening.

It is the most demanding of the three demos. The random graph demo asks the viewer to handle density. The random binary tree demo asks the viewer to handle hierarchy. The animation demo asks the viewer to handle change.

Why animation is different

A static graph picture can be wrong and still be readable. A graph picture in motion has to keep being right while the underlying graph changes. That is a different problem.

A few things become harder under animation:

  • Identity. The viewer has to track which node is which across changes. A node that moves to a new position is the same node. A new node that arrives at a similar position is a different node.
  • Continuity. A change should look like a change. A new edge should appear in a way that makes the new structure obvious. A removed edge should not just blink out.
  • Composure. The picture should not panic when changes arrive faster than the layout settles. A viewer that keeps re-running the layout from scratch becomes useless under load.

What to watch for

A few specific behaviours that the demo surfaces well:

  • Adding a node. Does the new node appear near related nodes, or in an arbitrary corner that then drifts toward its eventual home?
  • Removing a node. Does the picture collapse the gap gracefully, or does the whole graph shove sideways?
  • Adding an edge. Does the viewer pull the endpoints toward each other smoothly, or does it yank them?
  • Removing an edge. Does the picture settle into the new shape gracefully, or does it ring?
  • Bursts. When several changes happen in quick succession, does the picture stay readable between bursts?

The best viewers handle all of those gracefully. The most common failures are over-jitter (the picture moves more than it should) and bursty resets (the picture rearranges everything when only a small part changed).

A useful contrast

If you have ever used a graph viewer that re-runs the layout from scratch every time the graph changes, you know how disorienting that is. The picture looks completely different after a small change because the layout has no memory.

A viewer that handles animation well is doing the opposite. It is treating the previous layout as a starting point and adjusting from there. The picture remains recognisable. The change is what stands out, not the whole picture.

That continuity is one of the things that separates a graph viewer from a graph drawing program. Drawing programs produce a static picture. Viewers maintain a picture through change.

A conceptual sketch

The driver loop on the client side looks something like:

while True:
    action = pick_random_action()

    if action == "add_node":
        create_vertex()
    elif action == "remove_node":
        remove_random_vertex()
    elif action == "add_edge":
        create_edge(random_pair())
    elif action == "remove_edge":
        remove_random_edge()

    sleep(short_interval)

The viewer receives a stream of small changes. It does not get told to re-render the whole graph. That detail matters - the streaming model is what makes the animation demo possible without flicker.

If you want the longer write-up on how the streaming model works in practice, the docs index covers it, and the XML-RPC graph control lab note goes into the call patterns.

Pacing

Animation that is too fast loses the reader. Animation that is too slow loses the reader for a different reason. The demo lets you tune the interval between changes, and that single knob has a surprising effect on how the picture reads.

Three pacing regimes worth trying:

  • Slow (~1 second between changes). Every change is legible on its own. The picture as a whole reads less as a graph and more as a sequence of events.
  • Medium (~200 ms between changes). Changes blend into each other. The picture reads as a graph that is alive.
  • Fast (~30 ms between changes). The picture reads as a continuous flow. Individual changes are no longer legible but the overall shape of the graph is.

There is no single right pace. The right pace depends on what you want the reader to take away from the picture. The demo is a good place to develop a feel for the trade-off.

Where animation fails honestly

Animation is not a free win. There are situations where a static picture is better:

  • When the question is structural (“how is this graph connected?”), motion is a distraction.
  • When the reader is comparing two states (“how did the graph change between yesterday and today?”), a before-and-after image often beats animation.
  • When the picture is being captured for a printed page or a slide, animation cannot help.

The demo is not arguing that animation is always the right answer. It is showing what a viewer can do when animation is the right answer.

Where to go from here

If you came in from an old link, nothing has been moved. The demo lives at the same path it has always lived at.