alt Hacker NewsReally impressive - browser-based hardware emulation is a brutal WebAssembly performance problem. Curious what you're doing for the rendering layer: are the circuit visualizations on canvas/WebGL, or DOM-based? I've been hitting similar render-loop problems with a deck.gl mapping project (realtime vessel positions, thousands of points updating simultaneously) and the pattern I found that helped most was batching state updates on a fixed 2s interval before diffing the render layer - prevents the WebGL context from recomposing faster than the data actually changes meaningfully. Does Velxio have a similar throttle, or does it redraw on every emulation tick?
Thanks! The rendering is DOM-based, circuit components are Web Components (from the wokwi-elements library) wrapped in React, and wires are SVG. No Canvas/WebGL, which keeps it simple for the component count we're dealing with (typically dozens, not thousands).
The emulation itself is pure JavaScript (avr8js), not WebAssembly. The simulation loop runs on requestAnimationFrame and executes 267K AVR instructions per frame (16MHz / 60fps) in a synchronous batch. Port listeners use dirty-checking so the UI is only notified when a GPIO register actually changes value and since all those cycles run in one JS microtask, React reconciles exactly once per frame regardless of how many state changes happened during the batch
So there's no explicit throttle interval like your 2 sec approach, but the architecture achieves something similar. the CPU runs freely, state changes are coalesced within each rAF frame, and the DOM only sees the final result. For your deck.gl case with thousands of points, the 2s batch makes sense since you're dealing with a much higher entity count hitting the GPU , our problem domain is simpler (dozens of components) but the cycle-accurate emulation is the expensive part