Diagram - Performance

Choose large-model views, routing completion feedback and resource ownership for your application.

Choose virtualization and output budgets for your workload, then measure the actual scene, content and browser conditions. Record counts, mount caps and resource limits describe different boundaries. None alone establishes sustained frame time, completed paint or retained-heap behavior.

#Usage

Configure rich-view caps through Diagram.Viewport. This excerpt belongs inside an initialized root:

<Diagram.Viewport label="Review workflow" :virtualization="{ maxNodes: 160, maxConnectors: 300 }" style="height: 24rem" />

The complete saved model remains in the store. Virtualization bounds mounted rich components while aggregate SVG geometry represents other queried items. Keep durable values in the model because rich views can unmount and remount.

#Explore 10,000 nodes and 20,000 connectors

Pan through the graph, switch between Fit all and Local detail, or jump to Node 9000. Reveal hub opens Node 22, which connects across the entire model. Search by name or ID to find any node, including content outside the current viewport. At detail zoom, use Select to move nodes, drag the resize and rotation handles, then try Undo and Redo. Opening a destination selects its node and switches to the Select tool.

Loading Demo...

The demo uses a seed-613 navigation fixture: 10,000 variable-size nodes, 20,000 straight connectors, a high-degree hub, crossing edges and twenty remote children. The complete model stays in the store. The counters show actual mounted node and connector components, bounded at 160 and 300; aggregate SVG paths draw the remaining queried geometry. At overview zoom, rich node content gives way to the graph's silhouettes and connections.

The demo supports navigation and editing within a large graph. It uses simple node content and does not establish a maximum supported model size. For editable form state and view lifecycles, see Virtualization.

#Runtime Controls

Viewport virtualization is optional. With no override, the resolver uses its defaults. The visibility resolver normalizes overscan to 160 CSS pixels, hysteresis to 96 CSS pixels, overview zoom to 0.35, rich-node cap to 160 and connector-part cap to 300. Nonnegative overscan/hysteresis are converted to world space at current zoom; node/connector caps are floored and clamped to 4 to 1000 / 4 to 2000. Selection/focus/edit ownership can pin a bounded set of views. Remaining queried geometry uses aggregate overview silhouettes instead of every rich template.

Rich content cost depends on its actual form/chart/table/component work. Virtualization preserves the graph in the store/index while views remount. Persist field values in model data. Search/reveal uses semantic identity to reach offscreen content. See Virtualization.

Deferred routing yields work and reports pending/fallback diagnostics. A layout worker moves provider computation; validation, application and subsequent routing remain separate phases. The built-in cooperative executor is main-thread execution. See Routing and Layout execution.

#Choose the workload and view

Try the complete model you intend to edit, including labels, custom components, groups, routed connectors and external measurement providers. A sparse graph and a model with rich forms or dense crossings place different demands on projection and rendering. Fixture record counts are examples, not supported-capacity or response-time guarantees.

Use local detail for editing and an overview for navigation. Keep rich-view caps and overscan appropriate to the content, while checking that focused, selected and edited items remain reachable. Aggregate silhouettes preserve access to offscreen graph geometry without mounting every content component.

#Routing and layout completion

Pending routing is distinct from an accepted model edit. Applications should present pending, settled and fallback states clearly and retain the reported diagnostics. A layout worker handles provider computation; validation, application and connector settlement still have their own ownership and cancellation boundaries. Keep newer edits and disposed sessions from adopting old work.

#Resource ownership

Test mount/unmount, model replacement and cancelled asynchronous work with your real node templates and providers. Release listeners, workers, object URLs and external subscriptions with their owner. Keep durable content in the Store and give unsaved local drafts an explicit owner so remounting does not silently lose them.

Observe the browser and actual user journeys when choosing application budgets. View counts, source limits and callback durations describe different boundaries; they do not establish completed paint, sustained responsiveness or retained-heap behavior. See SSR and lifecycle and Layout execution.