Live data from Hacker News

Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)

github.com

101–110 of 226 posts

Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)

#101
post #69

Right on time. We’ve been working on a browser-based Link Graph (osint) analysis tool for months now ( https://webvetted.com/workbench ). The graph charting tools on the market are pretty basic for the kind of charting we are looking to do (think 1000s of connected/disconnected nodes/edges. Being able to handle 1M points is a dream. This will come in very handy.

Agreed. This is highly, highly useful. Going to integrate this today.

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

Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)

#102
@huntergemmer - assuming you are the author, curious about your experience using .claude and .cursor, I see sub agents defined under these folders, what percent of your time spent would you say is raw coding vs prompting working on this project? And perhaps any other insights you may have on using these tools to build a library - see your first commit was only 5 days ago.

Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)

#103

Can it scroll while populating? I was trying to heart rate chart using libs which is captured at 60fps from camera (finger on camera with flash light). Raw drawing with canvas was faster than any libs. Drawing and scrolling live data was problem for a lib (dont remember which one) because it was drawing the whole thing on every frame.

Live streaming data is one of the examples: https://chartgpu.github.io/ChartGPU/examples/live-streaming/...

Although dragging the slider at the bottom is currently kind of broken as mentioned in another comment, seems like they are working on it though.

Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)

#104
uPlot maintainer here. this looks interesting, i'll do a deeper dive soon :)

some notes from a very brief look at the 1M demo:

- sampling has a risk of eliminating important peaks, uPlot does not do it, so for apples-to-apples perf comparison you have to turn that off. see https://github.com/leeoniya/uPlot/pull/1025 for more details on the drawbacks of LTTB

- when doing nothing / idle, there is significant cpu being used, while canvas-based solutions will use zero cpu when the chart is not actively being updated (with new data or scale limits). i think this can probably be resolved in the WebGPU case with some additional code that pauses the updates.

- creating multiple charts on the same page with GL (e.g. dashboard) has historically been limited by the fact that Chrome is capped at 16 active GL contexts that can be acquired simultaneously. Plotly finally worked around this by using https://github.com/greggman/virtual-webgl

> data: [[0, 1], [1, 3], [2, 2]]

this data format, unfortunately, necessitates the allocation of millions of tiny arrays. i would suggest switching to a columnar data layout.

uPlot has a 2M datapoint demo here, if interested: https://leeoniya.github.io/uPlot/bench/uPlot-10M.html

Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)

#105

Earlier quoted context omitted.

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

It's absolutely a veto button on something so pervasive. What is wrong with you JavaScript bros.

Not a JS bro here; low-level embedded/scientific programmer who does a lot of graphics and general compute work on GPUs.

Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)

#106

uPlot maintainer here. this looks interesting, i'll do a deeper dive soon :) some notes from a very brief look at the 1M demo: - sampling has a risk of eliminating important peaks, uPlot does not do it, so for apples-to-apples perf comparison you have to turn that off. see https://github.com/leeoniya/uPlot/pull/1025 for more details on the drawbacks of LTTB - when doing nothing / idle, there is significant cpu being…

Not much to add, but as a very happy uPlot user here - just wanted to say thank you for such an amazing library!!

Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)

#107

uPlot maintainer here. this looks interesting, i'll do a deeper dive soon :) some notes from a very brief look at the 1M demo: - sampling has a risk of eliminating important peaks, uPlot does not do it, so for apples-to-apples perf comparison you have to turn that off. see https://github.com/leeoniya/uPlot/pull/1025 for more details on the drawbacks of LTTB - when doing nothing / idle, there is significant cpu being…

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.

Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)

#108
post #86

If you have tons of datapoints, one cool trick is to do intensity modulation of the graph instead of simple "binary" display. Basically for each pixel you'd count how many datapoints it covers and map that value to color/brightness of that pixel. That way you can visually make out much more detail about the data. In electronics world this is what "digital phosphor" etc does in oscilloscopes, which started out as just…

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 don't need webgpu for that. It's a standard vertex shader -> fragment shader pass with the blending mode set to addition.

Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)

#109

Earlier quoted context omitted.

Really fantastic work! Can't wait to play around with your library. I did a lot of work on this at a past job long ago and the state of JS tooling was so inadequate at the time we ended up building an in-house Scala visualization library to pre-render charts... More directly relevant, I haven't looked at the D3 internals for a decade, but I wonder if it might be tractable to use your library as a GPU rendering engine…

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 cas…

Most of my use cases these days are for hobby projects, which I would bucket into the "data science"/"data journalism" category. I think this is the easiest audience to develop for, since people usually don't have any strict disciplinary norms apart from clean and sensible design. I mention double y-axes because in my own past library I stupidly assumed no sensible person would want such a chart -- only to have to rearchitect my rendering engine once I learned it was one of the most popular charts in finance.

That is, you're definitely developing the tool in a direction that I and I think most Hacker News readers will appreciate and it sounds like you're already thinking about some of the most common "extravagances" (annotations, reference lines, double y-axis etc). As OP mentioned, I think there's a big need for more performant client-side graph visualization libraries, but that's really a different project. Last I looked, you're still essentially stuck with graphviz prerendering for large enough graphs...

Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)

#110
Congrats, but 1M is nothing spectacular for apps in finance.

Here’s a demo of wip rendering engine we’re working on that boosted our previous capabilities of 10M data points to 100M data points.

https://x.com/TapeSurfApp/status/2009654004893339903?s=20

Post reply on HN