
Stardust: GPU-Based Visualization Library - borisjabes
https://stardustjs.github.io/
======
nothrabannosir
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?

~~~
Twirrim
On my desktop (Nvidia 750 Ti , Windows 10) I get 60fps with Chrome, Firefox,
and Edge on everything I've tried of the examples.

~~~
Twirrim
Gave that a shot on the (Intel Graphics) Macbook Pro and wow, didn't even
manage 10fps. Safari was worst of the lot.

------
kbenson
The link to the online playground is broken. It goes to [https://stardust-
vis.github.io/playground/](https://stardust-vis.github.io/playground/), but
since the project seems to be named stardustjs right now, I tried
[https://stardustjs.github.io/playground/](https://stardustjs.github.io/playground/)
and that worked.

~~~
sofaofthedamned
Yes, the link on the topbar works, not the one in the readme.

------
vanderZwan
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!

[0] [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Type...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Typed_arrays)

~~~
vsenko
Have you considered using dygraphs
([http://dygraphs.com/](http://dygraphs.com/))? It is designed to endure large
ammounts of data.

~~~
vanderZwan
Thanks for the suggestion, but it doesn't seem to support anything other than
line charts, which is too limited for our needs.

------
jszymborski
That force-graph demo is awesome... those things usually take down my browser
if they're non-trivial.

~~~
v-yadli
Totally agree. And it turns out not caused by the layout algorithm but exactly
the rendering.

We've been drawing on canvas without proper acceleration for too long.

~~~
lmeyerov
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!

------
WhitneyLand
What makes this library fast?

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.

~~~
bicubic
> 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.

------
gaetanrickter
I plan to use this to modify my approach in unsupervised visualizations
[https://hackernoon.com/unsupervised-machine-learning-for-
fun...](https://hackernoon.com/unsupervised-machine-learning-for-fun-profit-
with-basket-clusters-17a1161e7aa1)

------
jacquesm
Impressive, works like a charm on Firefox/Linux.

------
ruleabidinguser
This is awesome

------
idibidiartists
D3 can use GPU shaders and is far more flexible. This is ok for canned vis,
not for custom data vis. Like Vega vs D3. D3 wins every time.

~~~
ruleabidinguser
What makes D3 more flexible?

~~~
ZeroCool2u
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.

~~~
domoritz
This may be a bit confusing but Vega only uses some D3 helpers, it does not
generate D3 code at any point. See [https://vega.github.io/vega/about/vega-
and-d3/](https://vega.github.io/vega/about/vega-and-d3/) for details.

But you high-level point is accurate, D3 is more expressive since you can use
all of JavaScript.

------
smrtinsert
All I can say is finally. Death to d3.

~~~
Aaron1011
What's wrong with d3?

~~~
FullMtlAlcoholc
It's not the easiest tool to learn

~~~
brian_herman
Doesn't that make it more fun/rewarding?

~~~
devdoomari
nope - d3 code is extremely imperative...

so after a couple of lines, they're somewhat unmaintainable to me...

but couldn't find anything that covers most of d3's features...

~~~
myrryr
d3 is extremely functional. You can write it imperative, but it becomes
unmaintainable pretty quickly.

