Inviwo Tutorials: Network evaluation and event propagation

Main ideas and concepts

• Purpose of the video: Explain how an Inviwo network is executed, focusing on:
  • The order of processor execution
  • Event handling (how changes propagate through the network)
  • The invalidation mechanism (how Inviwo decides which processors must be re-evaluated)

Initial execution rule (“fresh workspace”)

• Data flows from top to bottom in the network.
• Therefore, on startup, all processors are executed top-to-bottom because downstream processors depend on upstream outputs.

Ongoing execution rule (“only when necessary”)

• After the initial run, Inviwo re-executes processors only if they are marked invalid.
• A processor becomes invalid/outdated when it is affected by an event, such as:
  • Changing a processor property
  • Other triggers like network/canvas size changes

Invalidation propagation

• If one processor becomes invalid, then:
  • All processors that depend on its output become invalid too
• This can cause a cascade: even if the invalid processor is “near the top,” it can invalidate everything below it.

---

Detailed methodology / step-by-step process (example: resizing the canvas)

When the canvas size changes, Inviwo triggers a resize event. The subtitles describe how that event and the resulting invalidation propagate:

1. Canvas emits resize event

   • The canvas triggers a resize event.

2. Resize event reaches processors connected to frame buffers

   • The event is relevant to processors that write into a frame buffer.
   • Frame buffers are transported through image ports.

3. Event propagation through image ports (step-by-step trace)

   • The resize event propagates from the canvas through its image in-port to the background processor.
   • The background processor:
     • Adjusts its output resolution accordingly
     • Then propagates the resize event upstream to the volume raycaster
   • The volume raycaster:
     • Makes similar output resolution changes
     • Propagates the event upwards through each of its connected image in-ports.

4. Terminal processors

   • The entry/exit point and mesh renderer processors:
     • Either don’t propagate the resize event further (e.g., because they have no image imports to forward),
     • Or they are not connected in a way that forwards the event.

5. Resulting invalidation

   • As a consequence of the resize event, the processors shown as “red” in the example are marked invalid.

6. Re-evaluation order

   • Inviwo then:
     • Finds the topmost invalid processors
     • Re-evaluates processors in an order such that each processor is executed only once.

7. Actual execution order shown (from console logs)

   • Entry/exit points & mesh renderer
   • Then volume raycaster
   • Then background
   • Finally canvas

8. Output propagation after re-evaluation

   • After reevaluation, each processor’s newly computed output is passed along to downstream processors.
   • In this scenario, all reevaluated processors were already invalid.
   • Generally, invalidation can also affect only one processor, but dependent downstream processors will still become invalid.

---

Lessons / takeaways

• Initial run: execute top-to-bottom.
• Incremental updates: execute only invalidated processors.
• Events cause invalidation, and invalidation cascades to dependent processors.
• Inviwo chooses a minimal re-evaluation schedule so that processors are executed at most once per update triggered by events.

---

Speakers / sources featured

• Speaker: Dominik