9 ms·

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

670 points by huntergemmer 8mo ago

Creator here. I built ChartGPU because I kept hitting the same wall: charting libraries that claim to be "fast" but choke past 100K data points. The core insight: Canvas2D is fundamentally CPU-bound. Even WebGL chart libraries still do most computation on the CPU. So I moved everything to the GPU via WebGPU: - LTTB downsampling runs as a compute shader - Hit-testing for tooltips/hover is GPU-accelerated - Rendering uses instanced draws (one draw call per series) The result: 1M points at 60fps with smooth zoom/pan. Live demo: https://chartgpu.github.io/ChartGPU/examples/million-points/ https://chartgpu.github.io/ChartGPU/examples/million-points/ Currently supports line, area, bar, scatter, pie, and candlestick charts. MIT licensed, available on npm: `npm install chartgpu` Happy to answer questions about WebGPU internals or architecture decisions.

deleted 8mo ago
[deleted]
keepamovin 8mo ago
Wa, this is smooth, man. This is so cool. This is really sexy and cool, the examples page (https://chartgpu.github.io/ChartGPU/examples/index.html https://chartgpu.github.io/ChartGPU/examples/index.html) has many good. 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!
- huntergemmer 8mo ago
  Thanks! The name was honestly just "what does this do" + "how does it do it" haha. Interesting you mention three.js - there's definitely overlap in the WebGPU graphics space. My focus is specifically on 2D data visualization (time series, financial charts, dashboards), but I could see the rendering patterns being useful elsewhere. On sustainability - still figuring that out. For now it's a passion project, but I've thought about a "pro" tier for enterprise features (real-time collaboration, premium chart types) while keeping the core MIT forever. Open to ideas if you have thoughts. Appreciate the kind words! :)
  - PxldLtd 8mo ago
    Have you thought about leaning into some of the fintech space? They'd happily pay for the sorts of features they need to stream financial data (which is usually bazillions of data points) and graph it efficiently. Off the top of my head, look into Order Book Heatmaps, 3D Volatility Surfaces, Footprint Charts/Volatility deltas. Integrating drawing tools like Fibonacci Retracements, Gann Fans etc. It would make it very attractive to people willing to pay.
    - huntergemmer 8mo ago
      Absolute gold comment here :) This comment was buried yesterday. I'm sorry for the late response! I was thinking about a pro tier for this kind of specialized stuff. Core stays MIT forever, but fintech tooling could be paid. Of the chart types you listed, is there a preference for what gets done first? Order Book Heatmaps first?
      - PxldLtd 8mo ago
        No problem :) I asked a friend who's a bit closer to the space and he agrees, definitely Order Book Heatmaps. The speed you're getting would make this a killer feature. Competitors typically have to snapshot/aggregate because their graphing libraries are heavily CPU bound. Being able visualise level 2/3 data without downsampling is a big win. Also being able to smoothly roll back through the last 12hrs of tick-level history would be really neat too. I'd say the bare minimum feature set outside of that is going to be: - Non linear X axis for gaps/sessions - Crosshairs that snap to OHLC data - Logarithmic scales, Candlesticks, Heikin-Ashi, and Volume profiles - Getting the 'feel' nice so that you can quickly scale and drag (people are real sticklers for the feel of these tools) - Solid callbacks for events for exchange integration, people hate leaving their charts to place an order eg (onOrderModify etc) - Provide a nice websocket data ingestion pipeline - Provide an api so devs can integrate their own indicators, some sort of 'layers' API or something. Sorry if I can't be of more help as I'm just a hobbyist in this area!
        keepamovin 8mo ago
d--b 8mo ago
This looks great. Quick feedback, scrollbars don't work well on my mac mini M1. The bar seems to move twice as fast as the mouse.
- huntergemmer 8mo ago
  Thanks for the bug report! That's the data zoom slider - sounds like a momentum/inertia scrolling issue on macOS. Which demo were you on? (million-points, live-streaming, or sampling?) I'll test on M1 today and get a fix out. Really appreciate you taking the time to try it :)
  - abuldauskas 8mo ago
    I also noticed it. On million-points. MacBook Pro M2 on Firefox Nightly 148.0a1 (2026-01-09) (aarch64)
  - qayxc 8mo ago
    Same issue on Windows - doesn't seem to be OS-related, but a general problem. The sliders and the zoom are basically unusable.
  - monegator 8mo ago
    On windows 10, too. Firefox 147.0.1 (You may want to update your "supported" chart! Firefox has WebGPU now)
- mikepurvis 8mo ago
  I see the same on Windows 11, both FF and Chrome.
justplay 8mo ago
Amazing. I can't express how thankful I am for you building this.
ranger_danger 8mo ago
No Firefox support? It has had WebGPU support since version 141. 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.
- jsheard 8mo ago
  Which platform? I think FF has only shipped WebGPU on Windows so far.
  - ranger_danger 8mo ago
    Linux, but apparently it's supported on both, but only enabled by default on Windows. I manually enabled it but it's still not working for me.
- embedding-shape 8mo ago
  Works for me with 146.0.1 (Linux) and having dom.webgpu.enabled set to true.
  - tonyplee 8mo ago
    Works for me too 145/Windows - default settings. Very cool project. Thanks!!!
- pier25 8mo ago
  FF has partial support for WebGPU https://caniuse.com/webgpu https://caniuse.com/webgpu
- call_to_action 8mo ago
  Working fine on latest FF for me, ~ v.146
embedding-shape 8mo ago
Fun benchmark :) I'm getting 165 fps (screen refresh rate), 4.5-5.0 in GPU time and 1.0 - 1.2 in CPU time on a 9970x + RTX Pro 6000. Definitely the smoothest graph viewer I've used in a browser with that amount of data, nicely done! 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 :)
- huntergemmer 8mo ago
  165 fps on that setup - that's awesome to hear! Thanks for testing on high-end hardware. Love the benchmark button idea. A "Run Benchmark" mode that captures: - Load time - GPU time - CPU time - Min/max/avg FPS over 10-15 seconds - Hardware info Then export a shareable summary or even a URL with encoded results. Would make for great comparison threads. Adding this to the roadmap - would make a great v0.2 feature. Thanks for the suggestion!
  - zamadatix 8mo ago
    Just to emphasize how good the performance is, I get 34.7 FPS on the Million Points demo... with sampling disabled and fully zoomed out!!!
dvh 8mo ago
Doesn't work on my Android phone because no GPU (but I have webgl is that not enough?)
- embedding-shape 8mo ago
  You have a GPU, and you have WebGL but what's missing is WebGPU support, the latest way of doing GPU-stuff in browsers.
- PxldLtd 8mo ago
  https://caniuse.com/webgpu https://caniuse.com/webgpu latest Android Chrome should have WebGPU support. You might need to update.
- ivanjermakov 8mo ago
  You have as much GPU as you have Web.
- bhouston 8mo ago
  Here is the breakdown of WebGPU support across various devices: https://web3dsurvey.com/webgpu https://web3dsurvey.com/webgpu
facontidavide 8mo ago
Cool to see that this project started 5 days ago! Unfortunately, I can not make it work on my system (Ubuntu, chrome, WebGPU enabled as described in the documentation). On the other hand, It works on my Android phone... 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!
- ivanjermakov 8mo ago
  I was able to make WebGPU work (and work well!) in Chrome Linux by enabling Vulkan renderer in Chrome flags.
dapperdrake 8mo ago
When did WebGPU become good enough at compute shaders? When I tried and failed at digging through the spec about a year ago it was very touch and go. Maybe am just bad at reading specifications or finding the right web browser.
- embedding-shape 8mo ago
  In Chromium it's been good for a good while, judges still out on when it'll be good in Firefox. Safari I have no clue about, nor whatever Microsoft calls their browser today.
deleted 8mo ago
[deleted]
acedTrex 8mo ago
Both a .cursor AND a .claude folder, what a yikes. Slop post galore
- embedding-shape 8mo ago
  Why don't you judge the results, if the slop is so easy to detect, instead of using the mere indication of a particular tool to mean it's slop? Lazy.
  - acedTrex 8mo ago
    Because it is not reasonable to expend high effort to verify something that took no effort to create. That is not a workable long term solution. Instead you have to rely on low effort signals to signify if something is WORTH expending energy on.
    - embedding-shape 8mo ago
      I didnt read your comment, because it would take me longer than just writing: your comment looks like LLM slop.
      - acedTrex 8mo ago
        If thats your signal then you lock yourself out of all parts of this website, not the best heuristic
        embedding-shape 8mo ago
        Yeah, that'd be stupid right? I have the same mindset with projects and code. If it's a good project, it's a good project, I don't care what IDE they used. If the code is shit it's shit regardless of how it was produced. But at least point to something concrete so me and others could potentially learn something, or understand something better.
  - keepamovin 8mo ago
maximgeorge 8mo ago
[dead]
mcintyre1994 8mo ago
Very cool, I like the variety of demos! On the candle sticks streaming demo (https://chartgpu.github.io/ChartGPU/examples/candlestick-streaming/index.html https://chartgpu.github.io/ChartGPU/examples/candlestick-str...), the 1s/5m/15m etc buttons don't seem to do anything
- huntergemmer 8mo ago
  Good catch! Thanks for actually clicking around and finding this - added to my issue tracker.
  - fourthark 8mo ago
    Can't tell what this demo is streaming, looks like a static line but it's working hard on something. It can't seem to decide whether to display the top number in red or green either.
samradelie 8mo ago
Fantasic Hunter, congrats! 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!
- huntergemmer 8mo ago
  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. Moving the tooltip/label rendering to message-passing or a separate DOM layer For your use case with heavy data munging, you could also run just the data processing in a worker and pass the processed arrays to ChartGPU on the main thread - that might be a quicker win. Would you open an issue on GitHub? I'd love to understand your specific workload better. This feels like a v0.2 feature worth prioritizing.
  - pf1gura 8mo ago
    I am on the same boat. Current user and a fan of uPlot starting to hit performance limits. Thank you for this library, I will start testing it soon. On the topic of support for worker threads, in my current project I have multiple data sources, each handled by its own worker. Copying data between worker and main thread - even processed - can be an expensive operation. Avoiding it can further help with performance.
  - samradelie 8mo ago
    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 worker thread could provide the offscreen canvas as well as a stream of normalized, touch and pointer events, keyboard and wheel. Then in your worker listeners could handle these incoming events and treat them as if they were direct from the event listeners on the main thread; effectively, your library is thread agnostic. I'd be happy to discuss this on GitHub. I'll try to get to that today. See you there.
deburo 8mo ago
Nicely done. Will you be able to render 3D donuts? And even animations, say pick a slice & see it tear apart from the donut.
- huntergemmer 8mo ago
  Thanks! Currently focused on 2D charts. That's where the "big data" performance problem is most painful. 3D is coming (it's the same rendering pipeline), but I'd want to get the 2D story solid first before expanding scope. The slice animation is doable though - we already have animation infrastructure for transitions. An "explode slice on click" effect would be a fun addition to the pie/donut charts. What's your use case? Dashboard visuals or something else?
mikepurvis 8mo ago
I've always been a bit skeptical of JS charting libs that want to bring the entire data to the client and do the rendering there, vs at least having the option to render image tiles on the server and then stream back tooltips and other interactive elements interactively. 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.
- zozbot234 8mo ago
  > render image tiles on the server and then stream back tooltips and other interactive elements interactively. I guess the real draw here is smooth scrolling and zooming, which is hard to do with server-rendered tiles. There's also the case of fully local use, where server rendering doesn't make much sense.
- internetter 8mo ago
  > I've always been a bit skeptical of JS charting libs that want to bring the entire data to the client and do the rendering there, vs at least having the option to render image tiles on the server and then stream back tooltips and other interactive elements interactively. I agree, unfortunately no library I've found supports this. I currently SSR plots to SVG using observable plot and JSDom [0]. This means there is no javascript bundle, but also no interactivity, and observable doesn't have a method to generate a small JS sidecar to add interactivity. I suppose you could progressive enhance, but plot is dozens of kilobytes that I'd frankly rather not send. [0] https://github.com/boehs/site/blob/master/conf/templating/markdown/widgets/eval.js https://github.com/boehs/site/blob/master/conf/templating/ma...
  - switz 8mo ago
    I’ve had a lot of success rendering svg charts via Airbnb’s visx on top of React Server Components, then sprinkling in interactivity with client components. Worth looking into if you want that balance. It’s more low level than a full charting library, but most of it can run natively on the server with zero config. I’ve always found performance to be kind of a drag with server side dom implementations.
jeffbee 8mo ago
The number of points actually being rendered doesn't seem to warrant the webgpu implementation. It's similar to the number of points that cubism.js could throw on the screen 15 years ago.
barrell 8mo ago
I just rewrote all the graphs on phrasing [1] to webgl. Mostly because I wanted custom graphs that didn’t look like graphs, but also because I wanted to be able to animate several tens of thousands of metrics at a time. 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 https://phrasing.app
pier25 8mo ago
Very 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 https://caniuse.com/webgpu
- bhouston 8mo ago
  You can also see extension support for webgpu via https://web3dsurvey.com/webgpu https://web3dsurvey.com/webgpu
- sroussey 8mo ago
  It’s available everywhere if you are on newest OS and newest browser. Biggest issue is MacOS users with newer Safari on older MacOS.
  - kawogi 8mo ago
    Support for Firefox on Linux is still only in nightly (unless that changed "very" recently) This blocks progress (and motivation) on some of my projects.
    - Joeboy 8mo ago
      Apparently you can turn it on with about:config / dom.webgpu.enabled But personally, I'm not going to start turning on unsafe things in my browser so I can see the demo. I tried firefox and chromium and neither worked so pfft, whatever.
- johndough 8mo ago
  And even if WebGPU is enabled, the implementation might still be broken or inefficient in various ways. For example, Firefox uses some ridiculous polling-based approach [1] to check for completion, which disqualifies the implementation for many performance-critical applications. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1870699 https://bugzilla.mozilla.org/show_bug.cgi?id=1870699 And there is the issue of getting the browser to use the correct GPU in the first place, but that is a different can of worms.
- 8mo ago
deleted 8mo ago
[deleted]
azangru 8mo ago
Bug report: there is something wrong with the slider below the chart in the million-points example: https://chartgpu.github.io/ChartGPU/examples/million-points/index.html https://chartgpu.github.io/ChartGPU/examples/million-points/... While dragging, the slider does not stay under the cursor, but instead moves by unexpected distances.
- huntergemmer 8mo ago
  Thanks - you're the second person to report this! Same issue as the Mac M1 scrollbar bug reported earlier. Looks like the data zoom slider has a momentum/coordinate mapping issue. Bumping this up the priority list since multiple people are hitting it.
  - virgil_disgr4ce 8mo ago
    I also experienced this behavior :)
buckle8017 8mo ago
WebGPU is a security nightmare. The idea that GPU vendors are going to care about memory access violations over raw performance is absurd.
- the__alchemist 8mo ago
  Security is one aspect to consider. It's not a veto button!
  - buckle8017 8mo ago
    It's absolutely a veto button on something so pervasive. What is wrong with you JavaScript bros.
    - the__alchemist 8mo ago
      Not a JS bro here; low-level embedded/scientific programmer who does a lot of graphics and general compute work on GPUs.
amirhirsch 8mo ago
Very Nice. There is an issue with panning on the million point demo -- it currently does not redraw until the dragging velocity is below some threshold, but it should seem like the points are just panned into frame. It is probably enough to just get rid of the dragging velocity threshold, but sometimes helps to cache an entire frame around the visible range
hienyimba 8mo ago
Right on time. We’ve been working on a browser-based Link Graph (osint) analysis tool for months now (https://webvetted.com/workbench 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.
- huntergemmer 8mo ago
  That's a cool project! Just checked out the workbench. I should be upfront though: ChartGPU is currently focused on traditional 2D charts (line, bar, scatter, candlestick, etc.), not graph/network visualization with nodes and edges. That said, the WebGPU rendering patterns would translate well to force-directed graphs. The scatter renderer already handles thousands of instanced points - extending that to edges wouldn't be a huge leap architecturally. Is graph visualization something you'd want as part of ChartGPU, or would a separate "GraphGPU" type library make more sense? Curious how you're thinking about it.
  - agentcoops 8mo ago
    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. I guess the big question for the future of your project is whether you want to focus on the performance side of certain primitives or expand the library to encompass all the various types of charts/customization that users might want. Probably that would just be a different project entirely/a nightmare, but if feasible even for a subset of D3 you would get infinitely customizable charts "for free." https://github.com/d3/d3-shape https://github.com/d3/d3-shape might be a place to look. In my past life, the most tedious aspect of building such a tool was how different graph standards and expectations are across different communities (data science, finance, economics, natural sciences, etc). Don't get me started about finance's love for double y-axis charts... You're probably familiar with it, but https://www.amazon.com/Grammar-Graphics-Statistics-Computing/dp/0387245448 https://www.amazon.com/Grammar-Graphics-Statistics-Computing... is fantastic if you continue on your own path chart-wise and you're looking for inspiration.
jhatemyjob 8mo ago
I don't really care about this, like at all. But I just wanted to say, that's an amazing name. Well done.
rgreen 8mo ago
this is so well done, thanks for sharing it. i've been trying to communicate with people how we are living in the golden age of dev where things that previously couldn't have been created, now can be. this is an amazing example of that.
lacoolj 8mo ago
Doesn't work for me? Latest chrome, RTX 4080, what am I missing?
- cuvinny 8mo ago
  I had to enable it in both Firefox (about:config search webgpu) and in Chrome (chrome://flags and enable Unsafe WebGPU Support) on my linux machine.
  - lacoolj 8mo ago
    ahhh ok thanks!
33a 8mo ago
plot.ly has been able to do WebGL scatter plots with > 10 million points for years. There's a lot of libraries that can do this I think? https://plotly.com/python/performance/ https://plotly.com/python/performance/
pdyc 8mo ago
Wow, this is great. I practically gave up on rendering large data in EasyAnalytica because plotting millions of points becomes a bad experience, especially in dashboards with multiple charts. My current solution is to downsample to give an “overview” and use zoom to allow viewing “detailed” data, but that code is fragile. 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.
KellyCriterion 8mo ago
Curious: How does TradingView et.al. solves this problem? They should have the same limitations? (actually, Im a user of the site, though I never started digging down how they made id)
- artursapek 8mo ago
  Tradingview’s charts couldn’t handle a million data points. They typically just render a few thousand candlesticks at a time, which is trivial with well optimized Canvas code.
deleted 8mo ago
[deleted]
dfortes 8mo ago
> You are an elite WebGPU developer with deep expertise in modern GPU programming for the web. You are a master of the WebGPU API, WGSL shader language, compute shaders, and high-performance graphics rendering across all major browsers. This is just embarrassing.
imiric 8mo ago
This is great, but I don't see it being useful for most use cases. 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.
zokier 8mo ago
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 emulating analog scopes. Some examples are visible here https://www.hit.bme.hu/~papay/edu/DSOdisp/gradient.htm https://www.hit.bme.hu/~papay/edu/DSOdisp/gradient.htm
- huntergemmer 8mo ago
  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!
  - akomtu 8mo ago
    You don't need webgpu for that. It's a standard vertex shader -> fragment shader pass with the blending mode set to addition.
    - vanderZwan 8mo ago
      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.
      - akomtu 8mo ago
smusamashah 8mo ago
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.
- Mogzol 8mo ago
  Live streaming data is one of the examples: https://chartgpu.github.io/ChartGPU/examples/live-streaming/index.html 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.
mitdy 8mo ago
What purposes have you found for rendering so many datapoints? It seems like at a certain point, say above a few thousand, it becomes difficult to discriminate/less useful to render more in many cases
- aixnr 8mo ago
  [dead]
altern8 8mo ago
All charts in the demo failed for me. 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.".
- kettlecorn 8mo ago
  Does your browser support WebGPU yet? It's likely it does not. WebGPU is supported on Chrome and on the latest version of Safari. On Linux with all browsers WebGPU is only supported via an experimental flag.
  - altern8 8mo ago
    I'm not sure. I'm using the latest version of Chrome. Maybe I messed with the settings at some point and disabled something.
  - mahkoh 8mo ago
    WebGPU seems to be enabled by default in chromium 144 on linux at least on AMD GPUs.
- mholt 8mo ago
  I'm getting the same error, but ://gpu shows that WebGPU is "Hardware accelerated"
marginalx 8mo ago
@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.
leeoniya 8mo ago
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 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 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 https://leeoniya.github.io/uPlot/bench/uPlot-10M.html
- aurbano 8mo ago
  Not much to add, but as a very happy uPlot user here - just wanted to say thank you for such an amazing library!!
  - leeoniya 8mo ago
    yw!
- huntergemmer 8mo ago
  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.
yogitakes 8mo ago
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 https://x.com/TapeSurfApp/status/2009654004893339903?s=20
escapecharacter 8mo ago
I'd love to know if this is compatible as embedded in a Jupyter Notebook.
btbuildem 8mo ago
I like how you used actual financial data for the candlestick example :)
elAhmo 8mo ago
Safari on latest Sequoia doesn't support this. Given that many people will not upgrade to the latest version, it is a shame Safari is behind these things.
- dapperdrake 8mo ago
  Wait until you hear about the pixel size restrictions on safari canvases.
akdor1154 8mo ago
The rendering is very cool, but what i really want is this as a renderer i can plug into Vega. 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.
- Moosdijk 8mo ago
  There seems to be a webgl render engine suitable for vega [0]. Have you tried and if so, what was your experience? [0] https://github.com/vega/vega-webgl-renderer https://github.com/vega/vega-webgl-renderer
tempaccsoz5 8mo ago
TimeLine maintainer here. Their demo for live-streamed data [0] in a line plot is surprisingly bad given how slick the rest of it seems. For comparison, this [1] is a comparatively smooth demo of the same goal, but running entirely on the main thread and using the classic "2d" canvas rendering mode. [0]: https://chartgpu.github.io/ChartGPU/examples/live-streaming/index.html https://chartgpu.github.io/ChartGPU/examples/live-streaming/... [1]: https://crisislab-timeline.pages.dev/examples/live-with-plugins/ https://crisislab-timeline.pages.dev/examples/live-with-plug...
- kshri24 8mo ago
  The entire library seems to be AI generated [1] [2]. Not sure how much of it was actually written by a human and how much of it was AI. [1]: https://github.com/ChartGPU/ChartGPU/blob/main/.cursor/agents/webgpu-pro.md https://github.com/ChartGPU/ChartGPU/blob/main/.cursor/agent... [2]: https://github.com/ChartGPU/ChartGPU/blob/main/.claude/agents/webgpu-expert.md https://github.com/ChartGPU/ChartGPU/blob/main/.claude/agent...
  - bobmoretti 8mo ago
    Given that the author's post and comments all sound like they were run through an LLM, I'm not at all surprised.
  - janice1999 8mo ago
    That was obvious before even looking at the repo because the OP used "the core insight" in the intro. Other telltale signs of these type of AI projects: - new account - spamming the project to HN, reddit etc the moment the demo half works - single contributor repo - Huge commits minutes apart - repo is less than a week old (sometimes literally hours) - half the commits start with "Enhance" - flashly demo that hides issues immediately obvious to experts in the field - author has slop AI project(s) OP uses more than one branch so he's more sophisticated than most.
volkercraig 8mo ago
> I kept hitting the same wall: charting libraries that claim to be "fast" but choke past 100K data points 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.
ycombadmin3 8mo ago
[dead]
Andr2Andr 8mo ago
Will it be possible to plot large graphs/ networks with thousands of nodes?
mdulcio 8mo ago
Have you tried rendering 30 different instances at the same time?
dangoodmanUT 8mo ago
Some of these don't feel 60fps, like the streaming one. I don't really know how to verify that though. Or maybe i'm just so used to 144fps.
huntergemmer 8mo ago
Quick update: Just shipped a fix for the data zoom slider bug that several of you reported (thanks d--b, azangru, and others). 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! :)
kayson 8mo ago
Zoom doesn't seem to work on Firefox mobile. Just zooms the whole page in.
SeasonalEnnui 8mo ago
What'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.
- olau 8mo ago
  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.
  - SeasonalEnnui 8mo ago
    Yeah I agree, I'd like to get an idea of the order-of-magnitude of difference between the two approaches by trying it out but realistically I don't think there's an easy way to get a i16 raw array into the browser runtime with minimal overhead (WebRTC maybe?)
  - dapperdrake 8mo ago
    That was also my research group's approach.
- rustystump 8mo ago
  I did something similar for syncing 10m particles in a sim for a multiplayer test. The gist is that at a certain scale it is cheaper to send a frame buffer but the scale needs to be massive. For this, compression/quantize numbers and then pass that directly to the gpu after it comes off the network. Have a compute shader on the gpu decompress before writing to a frame buffer. This is what high performance lidar streaming renderers do as lidar data is packed efficiently for transport.
rzmmm 8mo ago
Very cool project. Edward Tufte presented decades ago that great visualizations maximizes data-ink ratio. This is what he ment ;)
kirilln0v 8mo ago
What do you think about porting it to React Native using https://github.com/wcandillon/react-native-webgpu 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)
huntergemmer 8mo ago
Update: 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 :)
deleted 8mo ago
[deleted]
nova3000 8mo ago
Awesome stuff. just curious how much of this was written by AI autonomously ?
reactordev 8mo ago
Nice. Add some extras like being able to draw lines (for the candlesticks) and bands. Could just be an add on. The ability not only to plot things, but point them out is a must for me. 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.
popalchemist 8mo ago
Impressive! Most impressive.
huntergemmer 8mo ago
Update: Pushed some improvements to the candlestick streaming demo based on feedback from this thread. 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-streaming/ 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 :)
- mcintyre1994 8mo ago
  Pretty sure you have an extra 60x multiplier on all those time frames. Eg 1s shows 1 minute, 15m looks like 15 hours, 1D looks like 2 months.
rustystump 8mo ago
There is no problem with using ai but i strongly suspect that anyone can ask claud to make a gpu version of uplot and get a result of similar quality level here. AI emjois included. 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
Tiberium 8mo ago
The project (even if it's made with the help of LLMs) is nice, but the author writing all of his HN comments with LLMs is not.
- deepfriedrice 8mo ago
  Yeah this entire thread has a weird vibe. OP is clearly a competent engineer to have wrangled LLMs into building this (whether a 5 day old vibe code lib can survive this initial virality will be interesting to see), but seeing so much engagement with prototypical vacant LLM output is eerie
hdjrudni 8mo ago
Does this support stacked area charts? Like https://recharts.github.io/en-US/examples/StackedAreaChart/ https://recharts.github.io/en-US/examples/StackedAreaChart/ ? 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.
- huntergemmer 8mo ago
  Not yet - area charts work but stacking isn't implemented. I'll add this today for you :)
ColinEberhardt 8mo ago
Nice work! 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-points-with-d3.html https://blog.scottlogic.com/2020/05/01/rendering-one-million...
buibuibui 8mo ago
Is there a best practice how to stream and plot large signal data (e.g. > 1M data points of multiple sine waves) from a Python backend (e.g. numpy + FastAPI) to frontend? My current solution is: fetch ADC data, convert the bytes to base64 and embed it to JSON that will be send to the frontend. Frontend reverses this process and plot it to eCharts.
- dapperdrake 8mo ago
  How else is the data going to make it to your phone?
lelanthran 8mo ago
"The core insight" ...
niilokeinanen 8mo ago
Nice to see WebGPU experiments in data visualization field. But the description is certainly misleading. 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/ 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.
utf_8x 8mo ago
If this doesn't work for you on a reasonably recent version of Firefox, you can enable experimental (but in my experience quite stable) WebGPU support in `about:config` by setting `dom.webgpu.enabled` to true.
dapperdrake 8mo ago
Look at Stephen Few's website and books. http://perceptualedge.com/examples.php 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.
akst 8mo ago
I think I’d be interested in seeing something written about architectural decisions and how the architecture and your experience writing it differed from other non GPU projects (charting ideally but non-charting is fine too), and any unique hurdles you encountered in building this project?
facontidavide 8mo ago
Since I still see this on the front page, I am taking the liberty to plug my own funny experiment (still WIP). 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/ https://one-million-points-wasm.netlify.app/
mholt 8mo ago
Hmm, I'm getting "Failed to request WebGPU adapter. No compatible adapter found. This may occur if no GPU is available or WebGPU is disabled." but brave://flags reports that WebGPU is "Hardware accelerated." Any way for me to try this out?
Leonida5 8mo ago
This looks like yet another clone of Lightning Chart? SciChart cloned the library already?
abtgraphics 8mo ago
SciChart founder here, we've added ChartGPU vs. SciChart to our performance test suite - it holds up pretty well, but SciChart still about an order of magnitude faster https://github.com/ABTSoftware/javascript-chart-performance-test-suite/tree/add-chartgpu https://github.com/ABTSoftware/javascript-chart-performance-... Since the API is so new there may be some errors in the test suite, feel free to correct them Innovation like this is fantastic btw and is good for the community! WebGPU is an awesome technology. So, this not only pushes us to be better but also consider how to add value to customers/users

670 points by huntergemmer 8mo ago

deleted 8mo ago

[deleted]

keepamovin 8mo ago

Wa, this is smooth, man. This is so cool. This is really sexy and cool, the examples page (https://chartgpu.github.io/ChartGPU/examples/index.html https://chartgpu.github.io/ChartGPU/examples/index.html) has many good. 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!

huntergemmer 8mo ago
Thanks! The name was honestly just "what does this do" + "how does it do it" haha. Interesting you mention three.js - there's definitely overlap in the WebGPU graphics space. My focus is specifically on 2D data visualization (time series, financial charts, dashboards), but I could see the rendering patterns being useful elsewhere. On sustainability - still figuring that out. For now it's a passion project, but I've thought about a "pro" tier for enterprise features (real-time collaboration, premium chart types) while keeping the core MIT forever. Open to ideas if you have thoughts. Appreciate the kind words! :)
- PxldLtd 8mo ago
  Have you thought about leaning into some of the fintech space? They'd happily pay for the sorts of features they need to stream financial data (which is usually bazillions of data points) and graph it efficiently. Off the top of my head, look into Order Book Heatmaps, 3D Volatility Surfaces, Footprint Charts/Volatility deltas. Integrating drawing tools like Fibonacci Retracements, Gann Fans etc. It would make it very attractive to people willing to pay.
  - huntergemmer 8mo ago
    Absolute gold comment here :) This comment was buried yesterday. I'm sorry for the late response! I was thinking about a pro tier for this kind of specialized stuff. Core stays MIT forever, but fintech tooling could be paid. Of the chart types you listed, is there a preference for what gets done first? Order Book Heatmaps first?
    - PxldLtd 8mo ago
      No problem :) I asked a friend who's a bit closer to the space and he agrees, definitely Order Book Heatmaps. The speed you're getting would make this a killer feature. Competitors typically have to snapshot/aggregate because their graphing libraries are heavily CPU bound. Being able visualise level 2/3 data without downsampling is a big win. Also being able to smoothly roll back through the last 12hrs of tick-level history would be really neat too. I'd say the bare minimum feature set outside of that is going to be: - Non linear X axis for gaps/sessions - Crosshairs that snap to OHLC data - Logarithmic scales, Candlesticks, Heikin-Ashi, and Volume profiles - Getting the 'feel' nice so that you can quickly scale and drag (people are real sticklers for the feel of these tools) - Solid callbacks for events for exchange integration, people hate leaving their charts to place an order eg (onOrderModify etc) - Provide a nice websocket data ingestion pipeline - Provide an api so devs can integrate their own indicators, some sort of 'layers' API or something. Sorry if I can't be of more help as I'm just a hobbyist in this area!
      - keepamovin 8mo ago

d--b 8mo ago

This looks great. Quick feedback, scrollbars don't work well on my mac mini M1. The bar seems to move twice as fast as the mouse.

huntergemmer 8mo ago
Thanks for the bug report! That's the data zoom slider - sounds like a momentum/inertia scrolling issue on macOS. Which demo were you on? (million-points, live-streaming, or sampling?) I'll test on M1 today and get a fix out. Really appreciate you taking the time to try it :)
- abuldauskas 8mo ago
  I also noticed it. On million-points. MacBook Pro M2 on Firefox Nightly 148.0a1 (2026-01-09) (aarch64)
- qayxc 8mo ago
  Same issue on Windows - doesn't seem to be OS-related, but a general problem. The sliders and the zoom are basically unusable.
- monegator 8mo ago
  On windows 10, too. Firefox 147.0.1 (You may want to update your "supported" chart! Firefox has WebGPU now)
mikepurvis 8mo ago
I see the same on Windows 11, both FF and Chrome.

justplay 8mo ago

Amazing. I can't express how thankful I am for you building this.

ranger_danger 8mo ago

No Firefox support? It has had WebGPU support since version 141. 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.

jsheard 8mo ago
Which platform? I think FF has only shipped WebGPU on Windows so far.
- ranger_danger 8mo ago
  Linux, but apparently it's supported on both, but only enabled by default on Windows. I manually enabled it but it's still not working for me.
embedding-shape 8mo ago
Works for me with 146.0.1 (Linux) and having dom.webgpu.enabled set to true.
- tonyplee 8mo ago
  Works for me too 145/Windows - default settings. Very cool project. Thanks!!!
pier25 8mo ago
FF has partial support for WebGPU https://caniuse.com/webgpu https://caniuse.com/webgpu
call_to_action 8mo ago
Working fine on latest FF for me, ~ v.146

embedding-shape 8mo ago

Fun benchmark :) I'm getting 165 fps (screen refresh rate), 4.5-5.0 in GPU time and 1.0 - 1.2 in CPU time on a 9970x + RTX Pro 6000. Definitely the smoothest graph viewer I've used in a browser with that amount of data, nicely done! 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 :)

huntergemmer 8mo ago
165 fps on that setup - that's awesome to hear! Thanks for testing on high-end hardware. Love the benchmark button idea. A "Run Benchmark" mode that captures: - Load time - GPU time - CPU time - Min/max/avg FPS over 10-15 seconds - Hardware info Then export a shareable summary or even a URL with encoded results. Would make for great comparison threads. Adding this to the roadmap - would make a great v0.2 feature. Thanks for the suggestion!
- zamadatix 8mo ago
  Just to emphasize how good the performance is, I get 34.7 FPS on the Million Points demo... with sampling disabled and fully zoomed out!!!

dvh 8mo ago

Doesn't work on my Android phone because no GPU (but I have webgl is that not enough?)

embedding-shape 8mo ago
You have a GPU, and you have WebGL but what's missing is WebGPU support, the latest way of doing GPU-stuff in browsers.
PxldLtd 8mo ago
https://caniuse.com/webgpu https://caniuse.com/webgpu latest Android Chrome should have WebGPU support. You might need to update.
ivanjermakov 8mo ago
You have as much GPU as you have Web.
bhouston 8mo ago
Here is the breakdown of WebGPU support across various devices: https://web3dsurvey.com/webgpu https://web3dsurvey.com/webgpu

facontidavide 8mo ago

Cool to see that this project started 5 days ago! Unfortunately, I can not make it work on my system (Ubuntu, chrome, WebGPU enabled as described in the documentation). On the other hand, It works on my Android phone... 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!

ivanjermakov 8mo ago
I was able to make WebGPU work (and work well!) in Chrome Linux by enabling Vulkan renderer in Chrome flags.

dapperdrake 8mo ago

When did WebGPU become good enough at compute shaders? When I tried and failed at digging through the spec about a year ago it was very touch and go. Maybe am just bad at reading specifications or finding the right web browser.

embedding-shape 8mo ago
In Chromium it's been good for a good while, judges still out on when it'll be good in Firefox. Safari I have no clue about, nor whatever Microsoft calls their browser today.

deleted 8mo ago

[deleted]

acedTrex 8mo ago

Both a .cursor AND a .claude folder, what a yikes. Slop post galore

embedding-shape 8mo ago
Why don't you judge the results, if the slop is so easy to detect, instead of using the mere indication of a particular tool to mean it's slop? Lazy.
- acedTrex 8mo ago
  Because it is not reasonable to expend high effort to verify something that took no effort to create. That is not a workable long term solution. Instead you have to rely on low effort signals to signify if something is WORTH expending energy on.
  - embedding-shape 8mo ago
    I didnt read your comment, because it would take me longer than just writing: your comment looks like LLM slop.
    - acedTrex 8mo ago
      If thats your signal then you lock yourself out of all parts of this website, not the best heuristic
      - embedding-shape 8mo ago
        Yeah, that'd be stupid right? I have the same mindset with projects and code. If it's a good project, it's a good project, I don't care what IDE they used. If the code is shit it's shit regardless of how it was produced. But at least point to something concrete so me and others could potentially learn something, or understand something better.
- keepamovin 8mo ago

maximgeorge 8mo ago

[dead]

mcintyre1994 8mo ago

Very cool, I like the variety of demos! On the candle sticks streaming demo (https://chartgpu.github.io/ChartGPU/examples/candlestick-streaming/index.html https://chartgpu.github.io/ChartGPU/examples/candlestick-str...), the 1s/5m/15m etc buttons don't seem to do anything

huntergemmer 8mo ago
Good catch! Thanks for actually clicking around and finding this - added to my issue tracker.
- fourthark 8mo ago
  Can't tell what this demo is streaming, looks like a static line but it's working hard on something. It can't seem to decide whether to display the top number in red or green either.

samradelie 8mo ago

Fantasic Hunter, congrats! 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!

huntergemmer 8mo ago
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. Moving the tooltip/label rendering to message-passing or a separate DOM layer For your use case with heavy data munging, you could also run just the data processing in a worker and pass the processed arrays to ChartGPU on the main thread - that might be a quicker win. Would you open an issue on GitHub? I'd love to understand your specific workload better. This feels like a v0.2 feature worth prioritizing.
- pf1gura 8mo ago
  I am on the same boat. Current user and a fan of uPlot starting to hit performance limits. Thank you for this library, I will start testing it soon. On the topic of support for worker threads, in my current project I have multiple data sources, each handled by its own worker. Copying data between worker and main thread - even processed - can be an expensive operation. Avoiding it can further help with performance.
- samradelie 8mo ago
  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 worker thread could provide the offscreen canvas as well as a stream of normalized, touch and pointer events, keyboard and wheel. Then in your worker listeners could handle these incoming events and treat them as if they were direct from the event listeners on the main thread; effectively, your library is thread agnostic. I'd be happy to discuss this on GitHub. I'll try to get to that today. See you there.

deburo 8mo ago

Nicely done. Will you be able to render 3D donuts? And even animations, say pick a slice & see it tear apart from the donut.

huntergemmer 8mo ago
Thanks! Currently focused on 2D charts. That's where the "big data" performance problem is most painful. 3D is coming (it's the same rendering pipeline), but I'd want to get the 2D story solid first before expanding scope. The slice animation is doable though - we already have animation infrastructure for transitions. An "explode slice on click" effect would be a fun addition to the pie/donut charts. What's your use case? Dashboard visuals or something else?

mikepurvis 8mo ago

I've always been a bit skeptical of JS charting libs that want to bring the entire data to the client and do the rendering there, vs at least having the option to render image tiles on the server and then stream back tooltips and other interactive elements interactively. 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.

zozbot234 8mo ago
> render image tiles on the server and then stream back tooltips and other interactive elements interactively. I guess the real draw here is smooth scrolling and zooming, which is hard to do with server-rendered tiles. There's also the case of fully local use, where server rendering doesn't make much sense.
internetter 8mo ago
> I've always been a bit skeptical of JS charting libs that want to bring the entire data to the client and do the rendering there, vs at least having the option to render image tiles on the server and then stream back tooltips and other interactive elements interactively. I agree, unfortunately no library I've found supports this. I currently SSR plots to SVG using observable plot and JSDom [0]. This means there is no javascript bundle, but also no interactivity, and observable doesn't have a method to generate a small JS sidecar to add interactivity. I suppose you could progressive enhance, but plot is dozens of kilobytes that I'd frankly rather not send. [0] https://github.com/boehs/site/blob/master/conf/templating/markdown/widgets/eval.js https://github.com/boehs/site/blob/master/conf/templating/ma...
- switz 8mo ago
  I’ve had a lot of success rendering svg charts via Airbnb’s visx on top of React Server Components, then sprinkling in interactivity with client components. Worth looking into if you want that balance. It’s more low level than a full charting library, but most of it can run natively on the server with zero config. I’ve always found performance to be kind of a drag with server side dom implementations.

jeffbee 8mo ago

The number of points actually being rendered doesn't seem to warrant the webgpu implementation. It's similar to the number of points that cubism.js could throw on the screen 15 years ago.

barrell 8mo ago

I just rewrote all the graphs on phrasing [1] to webgl. Mostly because I wanted custom graphs that didn’t look like graphs, but also because I wanted to be able to animate several tens of thousands of metrics at a time. 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 https://phrasing.app

pier25 8mo ago

Very 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 https://caniuse.com/webgpu

bhouston 8mo ago
You can also see extension support for webgpu via https://web3dsurvey.com/webgpu https://web3dsurvey.com/webgpu
sroussey 8mo ago
It’s available everywhere if you are on newest OS and newest browser. Biggest issue is MacOS users with newer Safari on older MacOS.
- kawogi 8mo ago
  Support for Firefox on Linux is still only in nightly (unless that changed "very" recently) This blocks progress (and motivation) on some of my projects.
  - Joeboy 8mo ago
    Apparently you can turn it on with about:config / dom.webgpu.enabled But personally, I'm not going to start turning on unsafe things in my browser so I can see the demo. I tried firefox and chromium and neither worked so pfft, whatever.
johndough 8mo ago
And even if WebGPU is enabled, the implementation might still be broken or inefficient in various ways. For example, Firefox uses some ridiculous polling-based approach [1] to check for completion, which disqualifies the implementation for many performance-critical applications. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1870699 https://bugzilla.mozilla.org/show_bug.cgi?id=1870699 And there is the issue of getting the browser to use the correct GPU in the first place, but that is a different can of worms.
8mo ago

deleted 8mo ago

[deleted]

azangru 8mo ago

Bug report: there is something wrong with the slider below the chart in the million-points example: https://chartgpu.github.io/ChartGPU/examples/million-points/index.html https://chartgpu.github.io/ChartGPU/examples/million-points/... While dragging, the slider does not stay under the cursor, but instead moves by unexpected distances.

huntergemmer 8mo ago
Thanks - you're the second person to report this! Same issue as the Mac M1 scrollbar bug reported earlier. Looks like the data zoom slider has a momentum/coordinate mapping issue. Bumping this up the priority list since multiple people are hitting it.
- virgil_disgr4ce 8mo ago
  I also experienced this behavior :)

buckle8017 8mo ago

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

the__alchemist 8mo ago
Security is one aspect to consider. It's not a veto button!
- buckle8017 8mo ago
  It's absolutely a veto button on something so pervasive. What is wrong with you JavaScript bros.
  - the__alchemist 8mo ago
    Not a JS bro here; low-level embedded/scientific programmer who does a lot of graphics and general compute work on GPUs.

amirhirsch 8mo ago

Very Nice. There is an issue with panning on the million point demo -- it currently does not redraw until the dragging velocity is below some threshold, but it should seem like the points are just panned into frame. It is probably enough to just get rid of the dragging velocity threshold, but sometimes helps to cache an entire frame around the visible range

hienyimba 8mo ago

Right on time. We’ve been working on a browser-based Link Graph (osint) analysis tool for months now (https://webvetted.com/workbench 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.

huntergemmer 8mo ago
That's a cool project! Just checked out the workbench. I should be upfront though: ChartGPU is currently focused on traditional 2D charts (line, bar, scatter, candlestick, etc.), not graph/network visualization with nodes and edges. That said, the WebGPU rendering patterns would translate well to force-directed graphs. The scatter renderer already handles thousands of instanced points - extending that to edges wouldn't be a huge leap architecturally. Is graph visualization something you'd want as part of ChartGPU, or would a separate "GraphGPU" type library make more sense? Curious how you're thinking about it.
- agentcoops 8mo ago
  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. I guess the big question for the future of your project is whether you want to focus on the performance side of certain primitives or expand the library to encompass all the various types of charts/customization that users might want. Probably that would just be a different project entirely/a nightmare, but if feasible even for a subset of D3 you would get infinitely customizable charts "for free." https://github.com/d3/d3-shape https://github.com/d3/d3-shape might be a place to look. In my past life, the most tedious aspect of building such a tool was how different graph standards and expectations are across different communities (data science, finance, economics, natural sciences, etc). Don't get me started about finance's love for double y-axis charts... You're probably familiar with it, but https://www.amazon.com/Grammar-Graphics-Statistics-Computing/dp/0387245448 https://www.amazon.com/Grammar-Graphics-Statistics-Computing... is fantastic if you continue on your own path chart-wise and you're looking for inspiration.

jhatemyjob 8mo ago

I don't really care about this, like at all. But I just wanted to say, that's an amazing name. Well done.

rgreen 8mo ago

this is so well done, thanks for sharing it. i've been trying to communicate with people how we are living in the golden age of dev where things that previously couldn't have been created, now can be. this is an amazing example of that.

lacoolj 8mo ago

Doesn't work for me? Latest chrome, RTX 4080, what am I missing?

cuvinny 8mo ago
I had to enable it in both Firefox (about:config search webgpu) and in Chrome (chrome://flags and enable Unsafe WebGPU Support) on my linux machine.
- lacoolj 8mo ago
  ahhh ok thanks!

33a 8mo ago

plot.ly has been able to do WebGL scatter plots with > 10 million points for years. There's a lot of libraries that can do this I think? https://plotly.com/python/performance/ https://plotly.com/python/performance/

pdyc 8mo ago

Wow, this is great. I practically gave up on rendering large data in EasyAnalytica because plotting millions of points becomes a bad experience, especially in dashboards with multiple charts. My current solution is to downsample to give an “overview” and use zoom to allow viewing “detailed” data, but that code is fragile. 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.

KellyCriterion 8mo ago

Curious: How does TradingView et.al. solves this problem? They should have the same limitations? (actually, Im a user of the site, though I never started digging down how they made id)

artursapek 8mo ago
Tradingview’s charts couldn’t handle a million data points. They typically just render a few thousand candlesticks at a time, which is trivial with well optimized Canvas code.

deleted 8mo ago

[deleted]

dfortes 8mo ago

> You are an elite WebGPU developer with deep expertise in modern GPU programming for the web. You are a master of the WebGPU API, WGSL shader language, compute shaders, and high-performance graphics rendering across all major browsers. This is just embarrassing.

imiric 8mo ago

This is great, but I don't see it being useful for most use cases. 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.

zokier 8mo ago

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 emulating analog scopes. Some examples are visible here https://www.hit.bme.hu/~papay/edu/DSOdisp/gradient.htm https://www.hit.bme.hu/~papay/edu/DSOdisp/gradient.htm

huntergemmer 8mo ago
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!
- akomtu 8mo ago
  You don't need webgpu for that. It's a standard vertex shader -> fragment shader pass with the blending mode set to addition.
  - vanderZwan 8mo ago
    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.
    - akomtu 8mo ago

smusamashah 8mo ago

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.

Mogzol 8mo ago
Live streaming data is one of the examples: https://chartgpu.github.io/ChartGPU/examples/live-streaming/index.html 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.

mitdy 8mo ago

What purposes have you found for rendering so many datapoints? It seems like at a certain point, say above a few thousand, it becomes difficult to discriminate/less useful to render more in many cases

aixnr 8mo ago
[dead]

altern8 8mo ago

All charts in the demo failed for me. 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.".

kettlecorn 8mo ago
Does your browser support WebGPU yet? It's likely it does not. WebGPU is supported on Chrome and on the latest version of Safari. On Linux with all browsers WebGPU is only supported via an experimental flag.
- altern8 8mo ago
  I'm not sure. I'm using the latest version of Chrome. Maybe I messed with the settings at some point and disabled something.
- mahkoh 8mo ago
  WebGPU seems to be enabled by default in chromium 144 on linux at least on AMD GPUs.
mholt 8mo ago
I'm getting the same error, but ://gpu shows that WebGPU is "Hardware accelerated"

marginalx 8mo ago

@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.

leeoniya 8mo ago

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 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 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 https://leeoniya.github.io/uPlot/bench/uPlot-10M.html

aurbano 8mo ago
Not much to add, but as a very happy uPlot user here - just wanted to say thank you for such an amazing library!!
- leeoniya 8mo ago
  yw!
huntergemmer 8mo ago
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.

yogitakes 8mo ago

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 https://x.com/TapeSurfApp/status/2009654004893339903?s=20

escapecharacter 8mo ago

I'd love to know if this is compatible as embedded in a Jupyter Notebook.

btbuildem 8mo ago

I like how you used actual financial data for the candlestick example :)

elAhmo 8mo ago

Safari on latest Sequoia doesn't support this. Given that many people will not upgrade to the latest version, it is a shame Safari is behind these things.

dapperdrake 8mo ago
Wait until you hear about the pixel size restrictions on safari canvases.

akdor1154 8mo ago

The rendering is very cool, but what i really want is this as a renderer i can plug into Vega. 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.

Moosdijk 8mo ago
There seems to be a webgl render engine suitable for vega [0]. Have you tried and if so, what was your experience? [0] https://github.com/vega/vega-webgl-renderer https://github.com/vega/vega-webgl-renderer

tempaccsoz5 8mo ago

TimeLine maintainer here. Their demo for live-streamed data [0] in a line plot is surprisingly bad given how slick the rest of it seems. For comparison, this [1] is a comparatively smooth demo of the same goal, but running entirely on the main thread and using the classic "2d" canvas rendering mode. [0]: https://chartgpu.github.io/ChartGPU/examples/live-streaming/index.html https://chartgpu.github.io/ChartGPU/examples/live-streaming/... [1]: https://crisislab-timeline.pages.dev/examples/live-with-plugins/ https://crisislab-timeline.pages.dev/examples/live-with-plug...

kshri24 8mo ago
The entire library seems to be AI generated [1] [2]. Not sure how much of it was actually written by a human and how much of it was AI. [1]: https://github.com/ChartGPU/ChartGPU/blob/main/.cursor/agents/webgpu-pro.md https://github.com/ChartGPU/ChartGPU/blob/main/.cursor/agent... [2]: https://github.com/ChartGPU/ChartGPU/blob/main/.claude/agents/webgpu-expert.md https://github.com/ChartGPU/ChartGPU/blob/main/.claude/agent...
- bobmoretti 8mo ago
  Given that the author's post and comments all sound like they were run through an LLM, I'm not at all surprised.
- janice1999 8mo ago
  That was obvious before even looking at the repo because the OP used "the core insight" in the intro. Other telltale signs of these type of AI projects: - new account - spamming the project to HN, reddit etc the moment the demo half works - single contributor repo - Huge commits minutes apart - repo is less than a week old (sometimes literally hours) - half the commits start with "Enhance" - flashly demo that hides issues immediately obvious to experts in the field - author has slop AI project(s) OP uses more than one branch so he's more sophisticated than most.

volkercraig 8mo ago

> I kept hitting the same wall: charting libraries that claim to be "fast" but choke past 100K data points 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.

ycombadmin3 8mo ago

[dead]

Andr2Andr 8mo ago

Will it be possible to plot large graphs/ networks with thousands of nodes?

mdulcio 8mo ago

Have you tried rendering 30 different instances at the same time?

dangoodmanUT 8mo ago

Some of these don't feel 60fps, like the streaming one. I don't really know how to verify that though. Or maybe i'm just so used to 144fps.

huntergemmer 8mo ago

Quick update: Just shipped a fix for the data zoom slider bug that several of you reported (thanks d--b, azangru, and others). 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! :)

kayson 8mo ago

Zoom doesn't seem to work on Firefox mobile. Just zooms the whole page in.

SeasonalEnnui 8mo ago

What'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.

olau 8mo ago
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.
- SeasonalEnnui 8mo ago
  Yeah I agree, I'd like to get an idea of the order-of-magnitude of difference between the two approaches by trying it out but realistically I don't think there's an easy way to get a i16 raw array into the browser runtime with minimal overhead (WebRTC maybe?)
- dapperdrake 8mo ago
  That was also my research group's approach.
rustystump 8mo ago
I did something similar for syncing 10m particles in a sim for a multiplayer test. The gist is that at a certain scale it is cheaper to send a frame buffer but the scale needs to be massive. For this, compression/quantize numbers and then pass that directly to the gpu after it comes off the network. Have a compute shader on the gpu decompress before writing to a frame buffer. This is what high performance lidar streaming renderers do as lidar data is packed efficiently for transport.

rzmmm 8mo ago

Very cool project. Edward Tufte presented decades ago that great visualizations maximizes data-ink ratio. This is what he ment ;)

kirilln0v 8mo ago

What do you think about porting it to React Native using https://github.com/wcandillon/react-native-webgpu 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)

huntergemmer 8mo ago

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

deleted 8mo ago

[deleted]

nova3000 8mo ago

Awesome stuff. just curious how much of this was written by AI autonomously ?

reactordev 8mo ago

Nice. Add some extras like being able to draw lines (for the candlesticks) and bands. Could just be an add on. The ability not only to plot things, but point them out is a must for me. 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.

popalchemist 8mo ago

Impressive! Most impressive.

huntergemmer 8mo ago

Update: Pushed some improvements to the candlestick streaming demo based on feedback from this thread. 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-streaming/ 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 :)

mcintyre1994 8mo ago
Pretty sure you have an extra 60x multiplier on all those time frames. Eg 1s shows 1 minute, 15m looks like 15 hours, 1D looks like 2 months.

rustystump 8mo ago

There is no problem with using ai but i strongly suspect that anyone can ask claud to make a gpu version of uplot and get a result of similar quality level here. AI emjois included. 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

Tiberium 8mo ago

The project (even if it's made with the help of LLMs) is nice, but the author writing all of his HN comments with LLMs is not.

deepfriedrice 8mo ago
Yeah this entire thread has a weird vibe. OP is clearly a competent engineer to have wrangled LLMs into building this (whether a 5 day old vibe code lib can survive this initial virality will be interesting to see), but seeing so much engagement with prototypical vacant LLM output is eerie

hdjrudni 8mo ago

Does this support stacked area charts? Like https://recharts.github.io/en-US/examples/StackedAreaChart/ https://recharts.github.io/en-US/examples/StackedAreaChart/ ? 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.

huntergemmer 8mo ago
Not yet - area charts work but stacking isn't implemented. I'll add this today for you :)

ColinEberhardt 8mo ago

Nice work! 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-points-with-d3.html https://blog.scottlogic.com/2020/05/01/rendering-one-million...

buibuibui 8mo ago

Is there a best practice how to stream and plot large signal data (e.g. > 1M data points of multiple sine waves) from a Python backend (e.g. numpy + FastAPI) to frontend? My current solution is: fetch ADC data, convert the bytes to base64 and embed it to JSON that will be send to the frontend. Frontend reverses this process and plot it to eCharts.

dapperdrake 8mo ago
How else is the data going to make it to your phone?

lelanthran 8mo ago

"The core insight" ...

niilokeinanen 8mo ago

Nice to see WebGPU experiments in data visualization field. But the description is certainly misleading. 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/ 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.

utf_8x 8mo ago

If this doesn't work for you on a reasonably recent version of Firefox, you can enable experimental (but in my experience quite stable) WebGPU support in `about:config` by setting `dom.webgpu.enabled` to true.

dapperdrake 8mo ago

Look at Stephen Few's website and books. http://perceptualedge.com/examples.php 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.

akst 8mo ago

I think I’d be interested in seeing something written about architectural decisions and how the architecture and your experience writing it differed from other non GPU projects (charting ideally but non-charting is fine too), and any unique hurdles you encountered in building this project?

facontidavide 8mo ago

Since I still see this on the front page, I am taking the liberty to plug my own funny experiment (still WIP). 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/ https://one-million-points-wasm.netlify.app/

mholt 8mo ago

Hmm, I'm getting "Failed to request WebGPU adapter. No compatible adapter found. This may occur if no GPU is available or WebGPU is disabled." but brave://flags reports that WebGPU is "Hardware accelerated." Any way for me to try this out?

Leonida5 8mo ago

This looks like yet another clone of Lightning Chart? SciChart cloned the library already?

abtgraphics 8mo ago

SciChart founder here, we've added ChartGPU vs. SciChart to our performance test suite - it holds up pretty well, but SciChart still about an order of magnitude faster https://github.com/ABTSoftware/javascript-chart-performance-test-suite/tree/add-chartgpu https://github.com/ABTSoftware/javascript-chart-performance-... Since the API is so new there may be some errors in the test suite, feel free to correct them Innovation like this is fantastic btw and is good for the community! WebGPU is an awesome technology. So, this not only pushes us to be better but also consider how to add value to customers/users