GUI Rendering Optimizations
Relevant source files
The following files were used as context for generating this wiki page:
Arbor employs a suite of rendering optimizations designed to maintain high performance when visualizing large-scale code property graphs. These optimizations span both the native Rust-based arbor-gui and the Flutter-based arbor_visualizer, ensuring smooth interaction even when handling datasets exceeding 100,000 nodes.
The core objective of these optimizations is to provide a responsive user experience during complex operations such as force-directed layouts, real-time sync, and interactive impact analysis. By utilizing techniques like Level of Detail (LOD) rendering, spatial partitioning, and viewport culling, Arbor minimizes CPU and GPU overhead during rapid navigation of the "Logic Forest."
Sources: PR_DESCRIPTION.md:31-35, CHANGELOG.md:55-60, README.md:126-129
Visualizer Core Optimizations
The Flutter-based visualizer implements several algorithmic and rendering strategies to handle high node density and frequent updates from the Arbor server.
Spatial Partitioning and Culling
To achieve O(n log n) complexity for force-directed layouts, the visualizer uses a Barnes-Hut QuadTree. This reduces the computational requirements for calculating repulsive forces between nodes, which would otherwise scale at O(n²). Additionally, Viewport Culling is utilized to skip the rendering phase for any nodes or edges that fall outside the current visible area, significantly reducing draw calls.
Sources: PR_DESCRIPTION.md:35, CHANGELOG.md:57-58
Level of Detail (LOD) Rendering
The GraphPainter component utilizes Velocity-Based LOD and zoom-sensitive rendering. When a user pans or zooms rapidly, the system simplifies the visual representation of nodes to maintain a consistent 60 FPS. At low zoom levels, node details are abstracted to further reduce rendering complexity.
Sources: PR_DESCRIPTION.md:32-33, CHANGELOG.md:59
Performance Metrics Table
| Feature | Optimization Technique | Complexity/Impact |
|---|---|---|
| Force Layout | Barnes-Hut QuadTree | O(n log n) vs O(n²) |
| Dynamic Panning | Velocity-Based LOD | Maintains 60 FPS |
| Rendering | Viewport Culling | 100k+ node support |
| Data Transfer | Incremental Sled Sync | Reduced I/O overhead |
Sources: PR_DESCRIPTION.md:31-35, CHANGELOG.md:57-60
Data Synchronization and Loading
Optimizations are not limited to pixels; Arbor optimizes the data pipeline between the backend persistence layer and the GUI frontend.
Incremental Persistence and Sync
The backend uses sled for persistent storage, implementing an Incremental Sync strategy. Only "dirty" nodes (those modified since the last save) are written to disk using atomic batches. The Flutter visualizer leverages this by performing efficient data loading, ensuring that large graph states are restored quickly without re-indexing the entire codebase.
Sources: PR_DESCRIPTION.md:21-23, PR_DESCRIPTION.md:34
Server-Side Pre-computation
Before sending graph data to the GUI or Visualizer, the Arbor server pre-computes node centrality. This allows the GUI to prioritize the rendering of "Core Logic" or highly connected nodes and provides a better initial layout for the visualizer.
Sources: crates/arbor-cli/src/commands.rs:167-169, crates/arbor-cli/src/commands.rs:194-196
This diagram illustrates the flow of optimized data from the persistence layer through to the final rendering pipeline.
Sources: PR_DESCRIPTION.md:21-23, PR_DESCRIPTION.md:35, CHANGELOG.md:58-59
Native GUI (arbor-gui) Architecture
The arbor-gui is a lightweight, focused interface built with eframe and egui. It prioritizes functional efficiency over graphical intensity.
Lazy Loading and State Management
The GUI implements lazy loading for the codebase graph. The graph is only indexed or loaded into memory when an analysis is requested, preventing unnecessary memory consumption during initial startup.
Sources: crates/arbor-gui/src/app.rs:77-83
UI Interaction Flow
The GUI utilizes a structured update loop to handle symbol searching and impact analysis results without blocking the main UI thread.
Sequence of events within the Native GUI during symbol analysis.
Sources: crates/arbor-gui/src/app.rs:88-92, crates/arbor-gui/src/app.rs:115-125
UI Component Optimizations
- Spoiler Mode: File paths are hidden by default to reduce visual clutter and ensure privacy during screenshots, only rendering when explicitly clicked.
- Search History: The last 10 queries are cached in memory to allow instant re-analysis without re-typing.
- Image Loading: SVG support is handled via
egui_extrasandresvgfor crisp, resolution-independent iconography (e.g., the Arbor logo) without high bitmap overhead.
Sources: crates/arbor-gui/src/app.rs:65, crates/arbor-gui/src/app.rs:150-155, crates/arbor-gui/src/main.rs:30-36
Arbor's GUI rendering optimizations ensure that the transition from raw code to a visual "Logic Forest" is both performant and scalable. By combining efficient Rust-based logic with high-level rendering strategies in Flutter, the system effectively manages the complexity of modern codebases.
Sources: PR_DESCRIPTION.md:31-35, README.md:126-129