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 )
Thanks! Leon's uPlot is fantastic - definitely an inspiration.
Worker thread support via OffscreenCanvas is a great idea and WebGPU does support it. I haven't tested ChartGPU in a worker context yet, but the architecture should be compatible - we don't rely on DOM for rendering, only for the HTML overlay elements (tooltips, axis labels, legend).
The main work would be:
1. Passing the OffscreenCanvas to the worker
2. Moving the tooltip/label rendering to message-passing or a separate DOM layer
For your use case with heavy data munging, you could also run just the data processing in a worker and pass the processed arrays to ChartGPU on the main thread - that might be a quicker win.
Would you open an issue on GitHub? I'd love to understand your specific workload better. This feels like a v0.2 feature worth prioritizing.
You have a good point about doing zero copy transferables which would probably work.
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 am on the same boat. Current user and a fan of uPlot starting to hit performance limits. Thank you for this library, I will start testing it soon.
On the topic of support for worker threads, in my current project I have multiple data sources, each handled by its own worker. Copying data between worker and main thread - even processed - can be an expensive operation. Avoiding it can further help with performance.
Wow. Stellar work. The TS looks really proper on first glance. I think you're right on zeitgeist -- we're going to need a lot more fundamental tools like this to build AI apps.
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)
I might have missed something -- how do AI apps come into this? Was this application written with AI, or for AI applications in particular? (I don't imagine it uses AI for the actual layout management or anything like that)
I'm guessing because things like bolt.new, v0 etc work a lot better when they have high quality building blocks to work with? Still seems a bit of a stretch.
It’s much intuitive to provide drag and drop support rather than the user asking AI to change the layout, which is hars bolt.new or v0 works at the moment.
There are options to maintain the panels content within the DOM at all times (using an approach like you mentioned with display: none) and options to remove content from the DOM.
In terms of vanilla TS the library is almost entire written in vanilla TS with small wrapper libraries for Vue and React.
In theory wrappers could be written for other frameworks such as Angular (which is something I would like to get done this year)
Bleugh. Who is this article for? (good bait from the poster) Anyone who's done any kind of meaningful SPA dev knows this pattern does not scale & for newbies, this is poison.
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.
Watched the talk linked on brimdata.io - stoked to see what's coming out. As a Typescript dev like yourself, very interested in how the dynamic types in Zed could be generated into ts, live.
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!
reply