Editor Scene Snapshot Lane Demand
Purpose
The scene snapshot cache keeps editor tabs responsive by refreshing only the scene projections that visible tools actually need. It is the shared performance boundary behind authored, graph, runtime, and validation views.
How It Works
Dock tab descriptors register demand through the editor workbench demand registry. The cache then refreshes the requested lanes on their own cadence: authored data can update quickly, validation can be slower, runtime projections may wait for runtime inputs, and graph data should refresh only when graph tools need it.
Debug demand can request every lane, but normal tools should ask only for the lanes they render.
Steps
When adding a new editor tab, declare the snapshot lane it needs through the descriptor instead of forcing a global scene refresh. If the tab only renders static authored data, request the authored lane. If it needs validation badges, request the validation lane explicitly.
Use all-lane demand only for debug or inspection surfaces.
Expected Outputs
A successful integration refreshes only the lanes the visible tool needs, preserves the last good snapshot on I/O failure, and shows fresh validation or runtime state when the tab requests it.
Invariants
Hidden tabs should not keep expensive lanes hot. Lane refresh should preserve the last good snapshot when scene I/O fails. Validation and runtime lanes must not silently masquerade as fresh data after their inputs changed.
Common Mistakes
Common mistakes include requesting every lane from a normal tab, forgetting validation demand for badge-heavy views, refreshing hidden tabs, or replacing a lane error with stale-looking success data.
Recovery Paths
If a tab shows stale validation, check whether it registered validation lane demand. If editor performance drops after opening a dock tab, inspect whether it requests all lanes unnecessarily. Scene I/O errors should appear as lane state, not as partial projections that look valid.