Thanks! The name was honestly just "what does this do" + "how does it do it" haha.

Interesting you mention three.js - there's definitely overlap in the WebGPU graphics space. My focus is specifically on 2D data visualization (time series, financial charts, dashboards), but I could see the rendering patterns being useful elsewhere.

On sustainability - still figuring that out. For now it's a passion project, but I've thought about a "pro" tier for enterprise features (real-time collaboration, premium chart types) while keeping the core MIT forever. Open to ideas if you have thoughts.

Appreciate the kind words! :)

Thanks for the bug report! That's the data zoom slider - sounds like a momentum/inertia scrolling issue on macOS.

Which demo were you on? (million-points, live-streaming, or sampling?) I'll test on M1 today and get a fix out.

Really appreciate you taking the time to try it :)

I see the same on Windows 11, both FF and Chrome.

Works for me with 146.0.1 (Linux) and having dom.webgpu.enabled set to true.

Which platform? I think FF has only shipped WebGPU on Windows so far.

FF has partial support for WebGPU

https://caniuse.com/webgpu

165 fps on that setup - that's awesome to hear! Thanks for testing on high-end hardware.

Love the benchmark button idea. A "Run Benchmark" mode that captures: - Load time - GPU time - CPU time - Min/max/avg FPS over 10-15 seconds - Hardware info

Then export a shareable summary or even a URL with encoded results. Would make for great comparison threads.

Adding this to the roadmap - would make a great v0.2 feature. Thanks for the suggestion!

You have a GPU, and you have WebGL but what's missing is WebGPU support, the latest way of doing GPU-stuff in browsers.

https://caniuse.com/webgpu latest Android Chrome should have WebGPU support. You might need to update.

You have as much GPU as you have Web.

Here is the breakdown of WebGPU support across various devices: https://web3dsurvey.com/webgpu

I was able to make WebGPU work (and work well!) in Chrome Linux by enabling Vulkan renderer in Chrome flags.

In Chromium it's been good for a good while, judges still out on when it'll be good in Firefox. Safari I have no clue about, nor whatever Microsoft calls their browser today.

Why don't you judge the results, if the slop is so easy to detect, instead of using the mere indication of a particular tool to mean it's slop? Lazy.

.c? what a yikes. I took a quick look at the code and this application doesn't even have any machine code in it, it's just words like "while", "for", "if", "else" and other English words - someone back in 1970s, I'm sure.

Soon there will be only 3 factors that we will care about: API (easy to use and integrate), behavior (does it do what I want it to do?) and testability (do I have sufficient guaranty that the code doesn't have errors).

The fact that the code was generated by a human or a machine is less and less important.

Good catch! Thanks for actually clicking around and finding this - added to my issue tracker.

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.

Thanks! Currently focused on 2D charts. That's where the "big data" performance problem is most painful.

3D is coming (it's the same rendering pipeline), but I'd want to get the 2D story solid first before expanding scope.

The slice animation is doable though - we already have animation infrastructure for transitions. An "explode slice on click" effect would be a fun addition to the pie/donut charts.

What's your use case? Dashboard visuals or something else?

> render image tiles on the server and then stream back tooltips and other interactive elements interactively.

I guess the real draw here is smooth scrolling and zooming, which is hard to do with server-rendered tiles. There's also the case of fully local use, where server rendering doesn't make much sense.

> I've always been a bit skeptical of JS charting libs that want to bring the entire data to the client and do the rendering there, vs at least having the option to render image tiles on the server and then stream back tooltips and other interactive elements interactively.

I agree, unfortunately no library I've found supports this. I currently SSR plots to SVG using observable plot and JSDom [0]. This means there is no javascript bundle, but also no interactivity, and observable doesn't have a method to generate a small JS sidecar to add interactivity. I suppose you could progressive enhance, but plot is dozens of kilobytes that I'd frankly rather not send.

[0] https://github.com/boehs/site/blob/master/conf/templating/ma...

You can also see extension support for webgpu via https://web3dsurvey.com/webgpu

It’s available everywhere if you are on newest OS and newest browser.

Biggest issue is MacOS users with newer Safari on older MacOS.

Thanks - you're the second person to report this! Same issue as the Mac M1 scrollbar bug reported earlier.

Looks like the data zoom slider has a momentum/coordinate mapping issue. Bumping this up the priority list since multiple people are hitting it.

Security is one aspect to consider. It's not a veto button!

That's a cool project! Just checked out the workbench. I should be upfront though: ChartGPU is currently focused on traditional 2D charts (line, bar, scatter, candlestick, etc.), not graph/network visualization with nodes and edges. That said, the WebGPU rendering patterns would translate well to force-directed graphs. The scatter renderer already handles thousands of instanced points - extending that to edges wouldn't be a huge leap architecturally.

Is graph visualization something you'd want as part of ChartGPU, or would a separate "GraphGPU" type library make more sense? Curious how you're thinking about it.