81–90 of 226 posts
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)
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 thre…
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.…
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.
Both a .cursor AND a .claude folder, what a yikes. Slop post galore
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.
Earlier quoted context omitted.
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.
Healthy skepticism is certainly laudable, but too many llmuddites seem rather aggressive while whistling past their own graveyards.
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.
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
Drawing and scrolling live data was problem for a lib (dont remember which one) because it was drawing the whole thing on every frame.
Right on time. 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.
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…
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.
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.