Editor speed up!

[NoxTechnicalDevelopment]

This adds a few things to improve the quality and performance of the renderer:

• When zooming it calculates the device pixel ratio to help with the nodes which were getting really blurry at reasonable zoom levels
• The wires no longer takes profiling actions every frame which gained +20% fps alone on a 120 component schematic
• Now culls offscreen nodes and connections
• Fixed caching issues with the canvas store
• added await to some places when loading and deserializing

If I need to make any edits to this PR I am more than willing.

[AfterAStorm]

A few little issues, but a step in the right direction!

[AfterAStorm]

chrome_2026-07-05_13-30-52.mp4

edit: the video looks way better than how it actually was-- it's being recorded at a slower framerate & bitrate

Weird behavior:

• Current main doesn't lag, nor does it cull, so it's FPS is about always the same no matter the zoom
• This PR lags fully zoomed out, but it does cull, so the FPS gets significantly better while zoomed in
• If I remove culling (comment isBoundsVisible checks), there's still a noticeable (positive) difference while zoomed in, so maybe the Canvas itself is doing some culling.

But in theory, the PR should be significantly better, since it's not re-creating canvases nor invalidating* every frame, so I'm not 100% what changed.

This is with ~300 nodes and ~300 connections.
It's the nodes; turning state.drawConnections = false (state (EditorState) is flow.editor and not Editor, terrible name I know) has no performance effect.

[NoxTechnicalDevelopment]

Pt.1
Can I get a copy of that benchmark? In my use of current site I've never had it handle more than 100/100 above 10fps. I suspect it has something to do with the "more than 10 updates" error visible in the pre-PR console log.

Pre PR:

---

Post PR:

---

FPS Snippet (slopmachine generated):

(() => {
  let frames = 0
  let last = performance.now()
  const samples = []

  const box = document.createElement('div')
  box.style.cssText = `
    position:fixed;
    top:56px;
    right:8px;
    z-index:999999;
    padding:3px 6px;
    background:rgba(0,0,0,.65);
    color:white;
    font:14px monospace;
    border-radius:4px;
    pointer-events:none;
  `
  box.textContent = '0 fps'
  document.body.appendChild(box)

  function tick(now) {
    frames++

    if (now - last >= 300) {
      const fps = frames * 1000 / (now - last)
      samples.push(fps)
      if (samples.length > 10) samples.shift()

      const avg = samples.reduce((a, b) => a + b, 0) / samples.length
      box.textContent = `${Math.round(avg)} fps`

      frames = 0
      last = now
    }

    requestAnimationFrame(tick)
  }

  requestAnimationFrame(tick)
})()

[NoxTechnicalDevelopment]

It seems the canvas patch was already being detected by Chrome, so the canvas change actually has a negative impact one chrome because it did this already... somewhere. I don't think I'll find what exactly in Chrome causes this, but it does have a 3x speed up on Firefox and I assume all other non-chromium based browsers.

[NoxTechnicalDevelopment]

Fixed! (I hope). After doing more benchmarking I can say zoomed performance now gets faster as you zoom out, due to 34d7165

(Tests done on chrome)

Pre-PR Control [33 fps]:

---

Post-PR Before Patch [28 fps]:

---

Post-PR Post Patch [79 fps]:

[AfterAStorm]

For completeness and history, I'll copy my discord message here:

After a quick fetch and... compile?... it's still not remedied for me:
I just make a quick "benchmark" of 300 AND gates with no connections bench_300AND.flow

the current deployment is faster...? it's the average case of "it works on my machine" :(

Updates should have minimal impact since... well... they aren't doing very much.
The main reason for the "more than >10 updates" is to prevent it from slowing rendering-- really it should be done elsewhere (web worker, idle callback; ill see if i can do this later)

I'm not sure if it's my version of chrome, it giving https/domains a higher computational priority, or some other magical canvas issue

It almost feels like there's a memory leak as the performance just slowly deteriorates, but there shouldn't be!
With the machine-curated slop fps counter, PR gets ~20fps, main gets ~60fps...

part 2:
I think i'll go ahead and merge and assume any performance problems will be fixed later (with other optimizations)-- seems mostly browser dependent.