This runs like magic on an iPhone, but for some reason Chrome, Safari and FF on desktop (mac, recent mbp) it's sluggish as hell. Burning through CPU, 15fps for the force-graph.
I feel like something's wrong, but I don't even know where to start debugging this. Do I need to enable Chrome feature flags? Or do mbps just have less powerful gpus than iPhones?
I'm getting 0.5fps with Safari Technology Preview, and a smooth 60fps with the stock Safari. I'm wondering what's up with that? I've tried both with and without the relevant entries I could find in "Experimental features" (WebGL 2.0, WebGPU, and something I forgot)
Chrome and Firefox on Android, on my Pixel XL, don't rise above 32 FPS. Chrome is a bit more performant than FF but not by much. I think you're right in your assessment; the iPhone's GPU is much stronger than you might think.
Mobile phones actually have a surprisingly high pixel count compared to desktops. FHD displays are common, and QHD and even near 4K displays are pretty common.
I'm reading through the paper, and this library almost seems custom-built for my use-case: a data browser for datasets with arrays of hundreds of thousands of datapoints.
One of the reasons I didn't go with D3 or any of the existing charting frameworks is that they simply do not seem built with that quantity of data in mind. Not only the rendering, the whole model: data is all packed in trees of JS-objects (at least the examples I see).
I have simple data that can be represented as dense typed arrays[0], with all the performance benefits of such, and no library seems to make good use of that. If I read the documentation for Stardust correctly, it's an exception to that rule (which makes sense, because typed arrays were mainly introduced for the sake of WebGL).
Similarly they also seem to do smart things with avoiding having to re-upload data to the GPU. I really hope this lives up to my expectations, it would save me a whole lot of work!
For more scalable on both, generally happy to share Graphistry API keys -- ping pygraphistry@graphistry.com . At the 100K+ scale, you need to optimize both :)
I'm excited to see both Stardust and the related DeckGL project. We've internally built several related framework layers (ex: streaming for cloud GPU offloading), and picking accessible abstractions for different developer personas is hard. Stardust & DeckGL are both (potentially) enabling dedicated visualization engineers to work more closely with high performance computing engineers. That's impressive: we deferred that problem to focus energy on enabling embedding for regular web developers (which goes above stardust) and scaling to the next 1000X (which goes below/adjacent)... but at the expense of making it harder for non-webgl visualization engineers to work on parts of our stack.
Long-term, I think their mindset is right, so, I've definitely been enjoying these projects!
I thought there were already many GPU accelerated paths for graphics in the browser, even including basic CSS functionality which leverages hardware acceleration in a significant number of scenarios.
It's great to see this library, just thought that since a lot of visualizations don't require advanced graphics techniques that a lot of GPU benefit was already being realized.
> I thought there were already many GPU accelerated paths for graphics in the browser, even including basic CSS functionality which leverages hardware acceleration in a significant number of scenarios.
That is true, and therein lies the catch. Those paths must support a significant number of scenarios, which means they must be very generic. This incurs (comparatively) huge performance penalties.
Using webgl trades genericity for performance. To put a bunch of 2d coordinate points on a canvas like this library does, only requires the equivalent of 1-2% of CSS functionality that browsers have to go through for every DOM element. It also means that whatever you're drawing has no impact on the rest of the page layout so there's another ton of overheads the browser can skip.
Vega is built on D3. It's just operating at a higher level. It's like C++ vs Python. You can do anything in C++ you can do in Python, but it may take a lot more work.
Edit: from their paper: "We see Stardust as a complement to D3 instead of a replacement. Stardust is good at rendering a large number of marks and animate them with parameters, while D3 has better support for fine-grained control and styling on a small number of items. For example, to create a scatterplot with a large number of items, we can use D3 to render its axes and handle interactions such as range selections, and use Stardust to render and animate the points"
It's very deliberately a lower level framework, for maximum flexibility. If you just want a bar chart in a line or five of code, there are many libraries which build on top of it.
I feel like something's wrong, but I don't even know where to start debugging this. Do I need to enable Chrome feature flags? Or do mbps just have less powerful gpus than iPhones?