huntergemmer

Not yet - area charts work but stacking isn't implemented. I'll add this today for you :)

Down. Hit me up!

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

Absolute gold comment here :)

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?

Update: Pushed some improvements to the candlestick streaming demo based on feedback from this thread.

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

Update: Patched idle CPU usage while nothing is being rendered.

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

Quick update: Just shipped a fix for the data zoom slider bug that several of you reported (thanks d--b, azangru, and others).

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

Ha - the double y-axis story is exactly why I want to get it right. Better to build it in properly than bolt it on later.

"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.

Interesting idea - I haven't explored wavelet-based approaches but the intuition makes sense: decompose into frequency bands, keep the low-frequency trend, and selectively preserve high-frequency peaks that exceed some threshold.

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.

Really appreciate you taking the time to look, Leon - uPlot has been a huge inspiration for proving that browser charts don't have to be slow.

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.

Awesome - let me know how it goes! Happy to help if you hit any rough edges. GitHub issues or ping me here.

Thanks - and great question about direction. My current thinking: Focus on performance-first primitives for the core library. The goal is "make fast charts easy" not "make every chart possible." There are already great libraries for infinite customization (D3, Observable Plot) - but they struggle at scale.

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?

Great suggestion - density mapping is a really effective technique for overplotted data. Instead of drawing 1M points where most overlap, you're essentially rendering a heatmap of point concentration. WebGPU compute shaders would be perfect for this - bin the points into a grid, count per cell, then render intensity. Could even do it in a single pass. I've been thinking about this for scatter plots especially, where you might have clusters that just look like solid blobs at full zoom-out. A density mode would reveal the structure. Added to the ideas list - thanks for the suggestion!

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.

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.

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?

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!

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.

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

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

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