Scope
File: src/components/spatial/LiveDataView.tsx
Problem
The live telemetry view currently pushes every incoming WebSocket data point directly to the canvas draw loop. Under high-frequency bursts (50+ messages/second from grid sensors), the RAF loop cannot keep up, causing frame drops, event queue backpressure, and eventual browser tab unresponsiveness.
Requirements
- Implement a ring buffer (
src/utils/buffer.ts) that stores at most MAX_POINTS (200) values.
- Batch incoming data points — accumulate writes into a temporary array and flush to the ring buffer every
BATCH_INTERVAL (50ms).
- The draw loop reads from the ring buffer at display refresh rate (requestAnimationFrame), decoupled from data ingestion.
- Add a CPU monitor that dynamically reduces
MAX_POINTS if frame-to-frame time exceeds 33ms (<30 FPS).
- Expose a
throttle<T>(fn, wait) utility in src/utils/helpers.ts.
Resolution Strategy
- Buffer:
Array<number> with fixed capacity, push → slice(-MAX_POINTS).
- Flush logic: check
Date.now() - lastFlush >= BATCH_INTERVAL inside push function.
- Draw: read buffer ref directly in RAF callback — no React state involved.
Tags
spatial, performance, websocket, streaming
Scope
File:
src/components/spatial/LiveDataView.tsxProblem
The live telemetry view currently pushes every incoming WebSocket data point directly to the canvas draw loop. Under high-frequency bursts (50+ messages/second from grid sensors), the RAF loop cannot keep up, causing frame drops, event queue backpressure, and eventual browser tab unresponsiveness.
Requirements
src/utils/buffer.ts) that stores at mostMAX_POINTS(200) values.BATCH_INTERVAL(50ms).MAX_POINTSif frame-to-frame time exceeds 33ms (<30 FPS).throttle<T>(fn, wait)utility insrc/utils/helpers.ts.Resolution Strategy
Array<number>with fixed capacity, push →slice(-MAX_POINTS).Date.now() - lastFlush >= BATCH_INTERVALinside push function.Tags
spatial, performance, websocket, streaming