Earlier quoted context omitted.
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.…
You have a good point about doing zero copy transferables which would probably work. There is certainly something beautiful about your charging GPU code being part of a file that runs completely isolated in another thread along with our websocket Data fire hose Architecturally that could be something interesting where you expose a typed API wrapping postmessage where consumers wanting to bind the main thread to a wor…
Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
141–150 of 226 posts
Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
#142Very cool. Shame there's not a webgl fallback though. It will be a couple of years until webgpu adoption is good enough. https://caniuse.com/webgpu
+1
Please support a fallback, ideally a 2D one too. WebGPU and WebGL are a privacy nightmare and the former is also highly experimental. I don't mind sub-60 FPS rendering, but I'd hate having to enable either of them just to see charts if websites were to adopt this library.
The web is already bad requiring JavaScript to merely render text and images. Let's not make it any worse.
Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
#143What's the best way to get all those points from a backend into the frontend webgpu compute shader?
There doesn't seem to be a communication mechanism that has minimal memcopy or no serialization/deserialization, the security boundary makes this difficult.
I have a backend array of 10M i16 points, I want to get this into the frontend (with scale & offset data provided via side channel to the compute shader).
As it stands, I currently process on the backend and send the frontend a bitmap or simplified SVG. I'm curious to know about the opposite approach.
Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
#144Very cool project. Edward Tufte presented decades ago that great visualizations maximizes data-ink ratio. This is what he ment ;)
Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
#145Earlier quoted context omitted.
Drawing lots of single pixels with alpha blending is probably one of the least efficient ways to use the rasterizer though. A good compute shader implementation would be substantially faster.
At 1M points it hardly makes a difference. Besides, 1 point -> 1 pixel mapping is good enough for a demo, but in practice it will produce nasty aliasing artifacts because real datasets aren't aligned with pixel coordinates. So you have to draw each point as a 2x2 square at least with precise shading, and we are back to the rasterizer pipeline. Edit: what actually needs to be computed is the integral of the points dat…
Aren't we at petaflops now with GPUs? 1M or even 1G points should be no issue if it renders to a framebuffer and doesn't go through mountains af JS framework rubbish followed by mountains of GTK/Qt/.NET rubbish.
Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
#146What do you think about porting it to React Native using https://github.com/wcandillon/react-native-webgpu?
How do you think is it possible? Because on RN most of the Graph Libs on CPU or Skia (which is good but still utilise CPU for Path rendering)
Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
#147uPlot 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…
Original Flot maintainer here.
I once had to deal with many million data points for an application. I ended up mip-mapping them client-side.
But regarding sampling, if it's a line chart, you can sample adaptively by checking whether the next point makes a meaningfully visible difference measured in pixels compared to its neighbours. When you tune it correctly, you can drop most points without the difference being noticeable.
I didn't find any else doing that at the time, and some people seemed to have trouble accepting it as a viable solution, but if you think about it, it doesn't actually make sense to plot say 1 million points in a line chart 1000 pixels wide. On average that would make 1000 points per pixel.
Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
#148What's the best way to get all those points from a backend into the frontend webgpu compute shader? There doesn't seem to be a communication mechanism that has minimal memcopy or no serialization/deserialization, the security boundary makes this difficult. I have a backend array of 10M i16 points, I want to get this into the frontend (with scale & offset data provided via side channel to the compute shader). As it st…
Not sure, but I solved a similar problem many years ago, and ended up concluding it was silly to send all the data to the client when the client didn't have the visual resolution to show it anyway. So I sampled it adaptively client-side by precomputing and storing multiple zoom-levels. That way the client-side chart app would get the points and you could zoom in, but you'd only ever retrieve about 1000-2000 points at the time.
Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
#149Update: 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 :)
Re: Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
#150[deleted]