91–100 of 226 posts
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.
Which platform? I think FF has only shipped WebGPU on Windows so far.
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…
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.".
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.".
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.
Earlier quoted context omitted.
It’s available everywhere if you are on newest OS and newest browser. Biggest issue is MacOS users with newer Safari on older MacOS.
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.
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.
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.
Earlier quoted context omitted.
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…
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…
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?
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…
> 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…
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 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 computer on my desk only costs me the electric power to run it, and there's 0 network latency between it and the monitor on which I'm viewing charts. If I am visualizing some data and I want to rapidly iterate on the visualization or interact with it, there's no more ideal place for the data to reside than right there. DDR5 and GPUs will be cheap again, some day.
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