News for hackers. Stuff that matters.

A comment on Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps). Parent comment

Re:Show HN: ChartGPU – WebGPU-powered charting library (1M p... by huntergemmer on Wednesday January 21, 2026 @12:59PM (#46709094)
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!
[ Parent | on HN ]
Re:Show HN: ChartGPU – WebGPU-powered charting library (1M p... by akomtu on Wednesday January 21, 2026 @01:33PM (#46709568)
You don't need webgpu for that. It's a standard vertex shader -> fragment shader pass with the blending mode set to addition.
[ Parent | on HN ]
Re:Show HN: ChartGPU – WebGPU-powered charting library (1M p... by MindSpunk on Wednesday January 21, 2026 @02:31PM (#46710347)
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.
[ Parent | on HN ]
Re:Show HN: ChartGPU – WebGPU-powered charting library (1M p... by akomtu on Wednesday January 21, 2026 @03:11PM (#46710899)
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 dataset over each square pixel, and that depends on the shape of each point, even if it's smaller than a pixel.
[ Parent | on HN ]
Re:Show HN: ChartGPU – WebGPU-powered charting library (1M p... by dheera on Wednesday January 21, 2026 @05:31PM (#46712566)
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.
[ Parent | on HN ]
Re:Show HN: ChartGPU – WebGPU-powered charting library (1M p... by rustystump on Wednesday January 21, 2026 @11:29PM (#46715332)
Not true. Fill rate and memory speed is still a huge bottleneck. The issue is not “rubbish” but memory speed. It is almost always memory speed, cache, ram, disk etc.

There is this misconception that if one uses js or c# to tell a gpu what to do it is somehow slower than rust. It only is if you crunching data but moving memory to the gpu and telling gpu to crunch is virtually identical.

[ Parent | on HN ]
Re:Show HN: ChartGPU – WebGPU-powered charting library (1M p... by dheera on Thursday January 22, 2026 @12:47AM (#46715738)
PCIe 6.0 x16 delivers ~128 GB/s so the billion points can be loaded in milliseconds onto the GPU. The GPU's memory is much faster.
[ Parent | on HN ]
Re:Show HN: ChartGPU – WebGPU-powered charting library (1M p... by rustystump on Thursday January 22, 2026 @03:23AM (#46716579)
Most consumers dont have that and at 60 fps you are already maxing it out and more assuming os is doing nothing else. Bandwidth even on gpus is still the bottleneck.

Even then, when u write to a framebuffer directly in the gpu if the locations of the points are not contiguous you are thrashing. Rendering points very fast is still very much about reducing the data set down to bypass all the layers of memory walls.

[ Parent | on HN ]
Re:Show HN: ChartGPU – WebGPU-powered charting library (1M p... by dapperdrake on Thursday January 22, 2026 @08:49AM (#46719211)
No difference for human visuals or no difference for discrete data or no difference for "continuous" f32 data?
[ Parent | on HN ]
Re:Show HN: ChartGPU – WebGPU-powered charting library (1M p... by vanderZwan on Wednesday January 21, 2026 @02:28PM (#46710298)
That works if more overdraw = more intensity is all you care about, and may very well be good enough for many kinds of charts. But with heat map plots one usually wants a proper mapping of some intensity domain to a color map and a legend with a color gradient that tells you which color represents which value. Which requires binning, counting per bin, and determining the min and max values.
[ Parent | on HN ]
Re:Show HN: ChartGPU – WebGPU-powered charting library (1M p... by akomtu on Wednesday January 21, 2026 @03:06PM (#46710849)
Emm.. no, you just do one render pass to a temp framebuffer with 1 red channel, then another fragment shader maps it to an RGB palette.
[ Parent | on HN ]
Re:Show HN: ChartGPU – WebGPU-powered charting library (1M p... by vanderZwan on Thursday January 22, 2026 @04:24AM (#46716941)
Wait, does additional blending let you draw to temp framebuffers with high precision and without clamping? Even so you'd still need to know the maximum value of the temp framebuffer though.
[ Parent | on HN ]
Re:Show HN: ChartGPU – WebGPU-powered charting library (1M p... by akomtu on Thursday January 22, 2026 @04:08PM (#46725151)
That's what EXT_float_blend does. It's true, though, that you can't find the global min/max in webgl2. This could be done, theoretically, with mipmaps if only those mipmaps supported the max function.
[ Parent | on HN ]
Re:Show HN: ChartGPU – WebGPU-powered charting library (1M p... by vanderZwan on Friday January 23, 2026 @07:23AM (#46731654)
Couldn't you do that manually with a simple downscaling filter? I'd be very shocked if fragment shaders did not have a min or max function.

Repeatedly shrinking by a factor of two means log2(max(width, height)) passes, each pass is a quarter of the pixels of the previous pass so that's a total of 4/3 times the pixels of the original image. Should be low enough overhead, right?

[ Parent | on HN ]
Re:Show HN: ChartGPU – WebGPU-powered charting library (1M p... by akomtu on Friday January 23, 2026 @02:24PM (#46736631)
Sure, that will work, but it's log2 passes + temp framebuffers. As for overhead, I'm afraid it will eat a couple fps if you run it on every frame. In practice, though, I'm not sure that finding the exact maximum is that valuable for rendering: a good guess based on the dataset type will do. For example, if you need to render N points that tend to congregate in the center, using sqrt(N) as the heuristic for the maximum works very well.
[ Parent | on HN ]