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

In electronics world this is what "digital phosphor" etc does in oscilloscopes, which started out as just emulating analog scopes. Some examples are visible here https://www.hit.bme.hu/~papay/edu/DSOdisp/gradient.htm

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.

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

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

https://chartgpu.github.io/ChartGPU/examples/million-points/...

While dragging, the slider does not stay under the cursor, but instead moves by unexpected distances.

After the initial setup and learning curve, it was actually very easy. All in all, way less complicated than all the performance hacks I had to do to get 0.01% of the data to render half as smooth using d3.

Although this looks next level. I make sure all the computation happens in a single o(n) loop but the main loop still takes place on the cpu. Very well done

To anyone on the fence, GPU charting seemed crazy to me beforehand (classic overengineering) but it ends up being much simpler (and much much much smoother) than traditional charts!

[1] https://phrasing.app

[0]: https://chartgpu.github.io/ChartGPU/examples/live-streaming/...

[1]: https://crisislab-timeline.pages.dev/examples/live-with-plug...

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

https://plotly.com/python/performance/

However, this is pretty great; there really aren't that many use cases that require more than a million points. You might finally unseat dygraphs as the gold standard in this space.

Haha, Highcharts is a running joke around my office because of this. Every few years the business will bring in consultants to build some interface for us, and every time we will have to explain to them that highcharts, even with it's turbo mode enabled chokes on our data streams almost immediately.

Even when I turn on dom.webgpu.enabled, I still get "WebGPU is disabled by blocklist" even though your domain is not in the blocklist, and even if I turn on gfx.webgpu.ignore-blocklist.

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

https://caniuse.com/webgpu

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.

D3fc maintainer here. A few years back we added WebGL support to D3fc (a component library for people building their own charts with D3), allowing it to render 1m+ datapoints:

https://blog.scottlogic.com/2020/05/01/rendering-one-million...

That's what I'm using now but I gave it too much data and it takes like a minute to render so I'm quite interested in this.

Error message: "WebGPU Error: Failed to request WebGPU adapter. No compatible adapter found. This may occur if no GPU is available or WebGPU is disabled.".

Would be great if you had a button there one can press, and it does a 10-15 second benchmark then print a min/max report, maybe could even include loading/unloading the data in there too, so we get some ranges that are easier to share, and can compare easier between machines :)

One more issue is that some browser and OS combinations do not support WebGPU, so we will still have to rely on existing libraries in addition to this, but it feels promising.

I've been looking for a followup to uPlot - Lee who made uPlot is a genius and that tool is so powerful, however I need OffscreenCanvas running charts 100% in worker threads. Can ChartGPU support this?

I started Opus 4.5 rewrite of uPlot to decouple it from DOM reliance, but your project is another level of genius.

I hope there is consideration for running your library 100% in a worker thread ( the data munging pre-chart is very heavy in our case )

Again, congrats!

Funny enough, I am doing something very similar: a C++ portable (Windows, Linux MacOS) charting library, that also compile to WASM and runs in the browser...

I am still at day 2, so see you in 3 days, I guess!

All the optimizations mentioned except LTTB downsampling in compute shaders can be done in WebGL.

Web charts with > 1 M points and 60 FPS zooming/panning have been available since 2019. For example, here's a line chart with 100M points (100x more): https://lightningchart.com/lightningchart-js-demos/100M/

But still, love to see it. WebGPU will surely go forward slowly as these things naturally do, but practical experimentation is essential.

Drawing and scrolling live data was problem for a lib (dont remember which one) because it was drawing the whole thing on every frame.

Most high-level charting libraries already support downsampling. Rendering data that is not visible is a waste of CPU cycles anyway. This type of optimization is very common in 3D game engines.

Also, modern CPUs can handle rendering of even complex 2D graphs quite well. The insanely complex frontend stacks and libraries, a gazillion ads and trackers, etc., are a much larger overhead than rendering some interactive charts in a canvas.

I can see GPU rendering being useful for applications where real-time updates are critical, and you're showing dozens of them on screen at once, in e.g. live trading. But then again, such applications won't rely on browsers and web tech anyway.

This is just embarrassing.

By no mean it is as nice looking as your demo, but it is interesting to ME... C++, compiled to WASM, using WebGL. Works on Firefox too. M4 decimation.

https://one-million-points-wasm.netlify.app/

http://perceptualedge.com/examples.php

There is also ggplot, ggplot2 and the Grammar of Graphics by Leland Wilkinson. Sadly, Algebra is so incompatible with Geometry that I found the book beautiful but useless for my problem domains after buying and reading and pondering it.

Maybe am just bad at reading specifications or finding the right web browser.

I’ve written several of these in the past. Was going to write one in pure WebGPU for a project I’m working on but you beat me to it and now I feel compelled to try yours before going down yet another charting rabbit hole.

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)

Vega/VGlite have amazing charting expressivity in their spec language, most other charting libs don't come close. It would be very cool to be able to take advantage of that.

The code in the repo is pretty awful with zero abstraction of duplicated render pipeline building and ai slop comments all over the place like “last resort do this”. Do not use this for production code. Instead, prompt the ai yourself and use your own slop.

The performance here is also terrible given it is gpu based. A gpu based renderer done correctly should be able to hit 50-100m blocks/lines etc at 60fps zoom/panning.

It is a testament to how good ai is though and the power of the dunning kruger effect

I hope you have a way to monetize/productize this, because this has three.js potential. I love this. Keep goin! And make it safe (a way to fund, don't overextend via OSS). Good luck, bud.

Also, you are a master of naming. ChartGPU is a great name, lol!

The idea that GPU vendors are going to care about memory access violations over raw performance is absurd.