Debugging the node editor

I almost abandoned the first Nodes prototype when React began reporting Maximum update depth exceeded. The canvas could enter a feedback loop while React Flow measured custom node contents and the controlled node list rebuilt around those measurements. This was a state bug: moving the work to another thread would not have stopped the loop.

Later, the graph stayed correct but felt slow under heavy render work. Procedural textures and CPU image effects occupied the main thread while the same thread was expected to process input, update React Flow, and compose previews. That was a throughput problem. Similar symptoms did not justify one shared fix.

React Flow needs real dimension changes to initialize bounds and handles, so ignoring every measurement was not safe. Artifact instead compares each dimension report with the node’s current measured size and resizing state. Equivalent reports are discarded; genuine size, position, and selection changes continue.

The regression tests preserve that distinction: duplicate dimensions become no-ops while real measurements and interactions remain observable. The fix is small because the ownership rule is explicit: a repeated layout measurement is not a new document edit.

Manual profiling identified procedural-noise generation as the first pure CPU workload worth isolating. In the same local profiling scenario, moving it to a dedicated Web Worker raised heavy interaction from roughly 8–12 FPS to roughly 57 FPS or higher. A second boundary later moved CPU-only image-data effects through the same pattern.

Only serializable settings and transferable pixel buffers cross those boundaries. React Flow state, DOM events, canvas creation and composition, PixiJS filters, and live Three.js viewports remain on the main thread. The worker clients can call the same pure implementation on the main thread in tests, unsupported environments, failures, and timeouts, so worker availability does not create a second rendering model.

The local Playwright benchmark loads a synthetic graph, waits for its previews, then drags a node, changes an effect slider, and pans the canvas. It records frame timing and long tasks alongside thumbnail, document, layer, worker, and GPU measures. The report is designed for relative build comparisons rather than a universal score.

That distinction keeps future optimization honest. Initial-load work can still come from image decoding, a full-quality canvas pass, thumbnail scheduling, or GPU effects. The next change should follow the slow phase in repeated measurements instead of assuming that more worker boundaries are automatically better.