There is certainly something beautiful about your charging GPU code being part of a file that runs completely isolated in another thread along with our websocket Data fire hose

Architecturally that could be something interesting where you expose a typed API wrapping postmessage where consumers wanting to bind the main thread to a worker thread could provide the offscreen canvas as well as a stream of normalized, touch and pointer events, keyboard and wheel. Then in your worker listeners could handle these incoming events and treat them as if they were direct from the event listeners on the main thread; effectively, your library is thread agnostic.

I'd be happy to discuss this on GitHub. I'll try to get to that today. See you there.

I've been looking for a followup to uPlot - Lee who made uPlot is a genius and that tool is so powerful, however I need OffscreenCanvas running charts 100% in worker threads. Can ChartGPU support this?

I started Opus 4.5 rewrite of uPlot to decouple it from DOM reliance, but your project is another level of genius.

I hope there is consideration for running your library 100% in a worker thread ( the data munging pre-chart is very heavy in our case )

Again, congrats!

Technically speaking, I've long wondered about mount/unmount of components as panels are dragged about and their visibility changed. Sometimes it's more costly to mount/unmount than to display:none.

Second, you have basically a declarative structure for these panels, are there plans to expose a Vite plugin for example that could export saved TS layouts, where functions (ie: TS imports) map to the panel contents? (trying to think outside of JSX and more vanilla TS)

Fantastic work!

Instead of talking high-level framework agnostic code design and the multitudes of ways to fetch data (route based, state stores, authentication hooks, subscriptions, model composition , to name a few ); author goes deep into outdated React anti-patterns.

Everyone who has commented on this is spot on.