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 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 more code.
- creating multiple charts on the same page with GL (e.g. dashboard) has historically been limited by the fact that Chrome has a limit of 16 active GL contexts that can be acquired. Plotly finally solved this by using https://github.com/greggman/virtual-webgl
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
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!
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.
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.
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 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... is fantastic if you continue on your own path chart-wise and you're looking for inspiration.
Thanks - and great question about direction. My current thinking: Focus on performance-first primitives for the core library. The goal is "make fast charts easy" not "make every chart possible." There are already great libraries for infinite customization (D3, Observable Plot) - but they struggle at scale.
That said, the ECharts-style declarative API is intentionally designed to be "batteries included" for common cases. So it's a balance: the primitives are fast, but you get sensible defaults for the 80% use case without configuring everything. Double y-axis is a great example - that's on the roadmap because it's so common in finance and IoT dashboards. Same with annotations, reference lines, etc. Haven't read the Grammar of Graphics book but it's been on my list - I'll bump it up. And d3-shape is a great reference for the path generation patterns. Thanks for the pointers!
Question: What chart types or customization would be most valuable for your use cases?
my 2 cents: I'm one of these people that could possibly use your tool. However, the website doesnt give me much info. I'd urge you to add some more pages that showcase the product and what it can do with more detail. Would help capture more people imo.
@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.
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.
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.
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!
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.".
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!
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.
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.
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
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
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)
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.
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.
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.
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.
> 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.
> 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.
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.
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 )
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.
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.
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.
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 :)
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!
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?
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.
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.
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.
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!
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.
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.
Soon there will be only 3 factors that we will care about: API (easy to use and integrate), behavior (does it do what I want it to do?) and testability (do I have sufficient guaranty that the code doesn't have errors).
The fact that the code was generated by a human or a machine is less and less important.
.c? what a yikes. I took a quick look at the code and this application doesn't even have any machine code in it, it's just words like "while", "for", "if", "else" and other English words - someone back in 1970s, I'm sure.
Yeah, hypers need to cool their language down a bit and llmuddites need to acquire a bit of nuance. New technology tends to create large camps initially on both sides :)
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.
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.
Agree, but, ah, can you illuminate. <totally-offtopic data-but="i am intesnely curious"> Quite amazing 6000 points in under 3 months. Yuge. OK a few almost 1K posts, but they drop off. You must have some mega-point comments. Can you, eh, "point me" to a comment of yours that has a super amount of upvotes?
Sorry if this is weird, it's just I've never personally experienced a comment with anything more than 100 - 200 points. And that was RARE. I totally get if you don't want to...but like, what were your "kilopoint" comments, or thereabouts? </offtopic>
I think if you too retire, have nothing specific to do for some months, and have too much free time to discuss with strangers on the internet about a wide range of topics you ideally have strong opinions about, you too can get more HN karma than you know what to do with :)
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 more code.
- creating multiple charts on the same page with GL (e.g. dashboard) has historically been limited by the fact that Chrome has a limit of 16 active GL contexts that can be acquired. Plotly finally solved this by using https://github.com/greggman/virtual-webgl
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.
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.
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 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... is fantastic if you continue on your own path chart-wise and you're looking for inspiration.
That said, the ECharts-style declarative API is intentionally designed to be "batteries included" for common cases. So it's a balance: the primitives are fast, but you get sensible defaults for the 80% use case without configuring everything. Double y-axis is a great example - that's on the roadmap because it's so common in finance and IoT dashboards. Same with annotations, reference lines, etc. Haven't read the Grammar of Graphics book but it's been on my list - I'll bump it up. And d3-shape is a great reference for the path generation patterns. Thanks for the pointers!
Question: What chart types or customization would be most valuable for your use cases?
https://chartgpu.github.io/ChartGPU/examples/million-points/...
While dragging, the slider does not stay under the cursor, but instead moves by unexpected distances.
Looks like the data zoom slider has a momentum/coordinate mapping issue. Bumping this up the priority list since multiple people are hitting it.
Drawing and scrolling live data was problem for a lib (dont remember which one) because it was drawing the whole thing on every frame.
Although dragging the slider at the bottom is currently kind of broken as mentioned in another comment, seems like they are working on it though.
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.
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
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.".
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.
https://plotly.com/python/performance/
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!
https://caniuse.com/webgpu
[1] 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.
Biggest issue is MacOS users with newer Safari on older MacOS.
This blocks progress (and motivation) on some of my projects.
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.
Maybe am just bad at reading specifications or finding the right web browser.
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.
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.
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/ma...
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.
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!
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.
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.
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.
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 :)
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!
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?
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.
Very cool project. Thanks!!!
https://caniuse.com/webgpu
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.
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!
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! :)
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.
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 :)
The idea that GPU vendors are going to care about memory access violations over raw performance is absurd.
What is wrong with you JavaScript bros.
The fact that the code was generated by a human or a machine is less and less important.
Sorry if this is weird, it's just I've never personally experienced a comment with anything more than 100 - 200 points. And that was RARE. I totally get if you don't want to...but like, what were your "kilopoint" comments, or thereabouts? </offtopic>
So, apparently these are my five most upvoted comments (based on going through the first 100 pages of my own comments...):
- 238 - https://news.ycombinator.com/item?id=46574664 - Story: Don't fall into the anti-AI hype
- 127 - https://news.ycombinator.com/item?id=46114263 - Story: Mozilla's latest quagmire
- 92 - https://news.ycombinator.com/item?id=45900337 - Story: Yt-dlp: External JavaScript runtime now required f...
- 78 - https://news.ycombinator.com/item?id=46056395 - Story: I don't care how well your "AI" works
- 73 - https://news.ycombinator.com/item?id=46635212 - Story: The Palantir app helping ICE raids in Minneapolis
I think if you too retire, have nothing specific to do for some months, and have too much free time to discuss with strangers on the internet about a wide range of topics you ideally have strong opinions about, you too can get more HN karma than you know what to do with :)