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.
Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
101–110 of 226 posts
Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
#102Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
#103Can 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.
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)
#104some 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)
#105Earlier 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.
Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
#106uPlot 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…
Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
#107uPlot 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…
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)
#108If 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…
Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
#109Earlier 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…
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)
#110Here’s a demo of wip rendering engine we’re working on that boosted our previous capabilities of 10M data points to 100M data points.