[samradelie]

Fantasic Hunter, congrats!

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!

[huntergemmer]

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.

[samradelie]

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.

[pf1gura]

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.