https://www.linkedin.com/in/huntergemmer/

This comment was buried yesterday. I'm sorry for the late response!

I was thinking about a pro tier for this kind of specialized stuff. Core stays MIT forever, but fintech tooling could be paid.

Of the chart types you listed, is there a preference for what gets done first?

Order Book Heatmaps first?

You can now render up to 5 million candles. Just tested it - Achieved 104 FPS with 5M candles streaming at 20 ticks/second.

Demo: https://chartgpu.github.io/ChartGPU/examples/candlestick-str...

Also fixed from earlier suggestions and feedback as noted before:

- Data zoom slider bug has been fixed (no longer snapping to the left or right) - Idle CPU usage bug (added user controls along with more clarity to 1M point benchmark)

13 hours on the front page, 140+ comments and we're incorporating feedback as it comes in.

This is why HN is the best place to launch. Thanks everyone :)

One thing to note: I added a toggle to "Benchmark mode" in the 1M benchmark example - this preserves the benchmark capability while demonstrating efficient idle behavior.

Another thing to note: Do not be alarmed when you see the FPS counter display 0 (lol), that is by design :) Frames are rendered efficiently. If there's nothing to render (no dirty frames) nothing is rendered. The chart will still render at full speed when needed, it just doesn't waste cycles rendering the same static image 60 times per second.

Blown away by all of you amazing people and your support today :)

The slider should now track the cursor correctly on macOS. If you tried the million-points demo earlier and the zoom felt off, give it another shot.

This is why I love launching on HN - real feedback from people actually trying the demos. Keep it coming! :)

"Data science/data journalism" is a great way to frame the target audience. Clean defaults, sensible design, fast enough that the tool disappears and you just see the data.

And yeah, graphviz keeps coming up in this thread - clearly a gap in the ecosystem. Might be a future project, but want to nail the 2D charting story first and foremost.

Thanks for the thoughtful feedback - this is exactly the kind of input that shapes the roadmap.

My concern would be computational cost for real-time/streaming use cases. LTTB is O(n) and pretty cache-friendly. Wavelet transforms are more expensive, though maybe a GPU compute shader could make it viable.

The other question is whether it's "visually correct" for charting specifically. LTTB optimizes for preserving the visual shape of the line at a given resolution. Wavelet decomposition optimizes for signal reconstruction - not quite the same goal.

That said, I'd be curious to experiment. Do you have any papers or implementations in mind? Would make for an interesting alternative sampling mode.

Both points are fair:

1. LTTB peak elimination - you're right, and that PR is a great reference. For the 1M demo specifically, sampling is on by default to show the "it doesn't choke" story. Users can set sampling: 'none' for apples-to-apples comparison. I should probably add a toggle in the demo UI to make that clearer.

2. Idle CPU - good catch. Right now the render loop is probably ticking even when static. That's fixable - should be straightforward to only render on data change or interaction. Will look into it.

Would love your deeper dive feedback when you get to it. Always more to learn from someone who's thought about this problem as much as you have.

That said, the ECharts-style declarative API is intentionally designed to be "batteries included" for common cases. So it's a balance: the primitives are fast, but you get sensible defaults for the 80% use case without configuring everything. Double y-axis is a great example - that's on the roadmap because it's so common in finance and IoT dashboards. Same with annotations, reference lines, etc. Haven't read the Grammar of Graphics book but it's been on my list - I'll bump it up. And d3-shape is a great reference for the path generation patterns. Thanks for the pointers!

Question: What chart types or customization would be most valuable for your use cases?

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.

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

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?

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!

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.

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 :)

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! :)