Live data from Hacker News

D3-dag – Layout algorithms for visualizing directed acylic graphs

github.com

11–20 of 44 posts

Re: D3-dag – Layout algorithms for visualizing directed acylic graphs

#11
post #7
post #6

I've always found it incredibly challenging to layout control-flow graphs (used a lot by compilers), so nice that this exists!

I don’t understand that remark. This library is for directed acyclic graphs. Control flow graphs are directed, but generally have cycles.

It's sometimes helpful, during program analysis, to collapse each strongly-connected component (SCC) of a directed graph into a single placeholder node representing that SCC.

When you do this, you're guaranteed that the resulting graph is acyclic.

Re: D3-dag – Layout algorithms for visualizing directed acylic graphs

#13
post #2

The numbers in the circles are not neatly centered. They're a little off. Fixing that (center them perfectly) would make them visually much more appealing.

That will involve some optical alignment considering the actual shapes of the glyphs? I imagine one would get this feeling of not perfectly aligned even when the center of the bounding box of the numbers coincide with the center of the circle.

Re: D3-dag – Layout algorithms for visualizing directed acylic graphs

#14
post #13
post #2

The numbers in the circles are not neatly centered. They're a little off. Fixing that (center them perfectly) would make them visually much more appealing.

That will involve some optical alignment considering the actual shapes of the glyphs? I imagine one would get this feeling of not perfectly aligned even when the center of the bounding box of the numbers coincide with the center of the circle.

You could use the box from baseline to ascender instead of descender to ascender. Usually there aren't many strings where that would look imbalanced.

Looking at the actual characters risks having different alignment for different nodes, which would look bad as well.

Re: D3-dag – Layout algorithms for visualizing directed acylic graphs

#16
post #8

Another great option for the same family of problems is Viz.js[1], which is essentially Graphviz in your browser. Offers a number of different layout models and a ton of configuration options. [1] http://viz-js.com/

I love graphviz (ever since Sanjay Ghemawat of mapreduce fame showed me how to use it in a compiler to debug CFGs). However, it’s the main limitation, compared to these other systems, is that it’s algorithms aren’t incremental/interactive. They are a bit dated in that way.

Re: D3-dag – Layout algorithms for visualizing directed acylic graphs

#18
All these graph layout algorithms should ideally be run on the backend. Most of these js libraries are missing the point in trying to run layout in Javascript on the frontend. If you have a huge graph, you can't view all of it at once anyways and you're viewing a subset of it any 1 moment.

So the ideal library should be running the layout on the backend and the frontend should be plain dummy, simply showing each graph node at the position co-ordinate sent from the back-end.

Re: D3-dag – Layout algorithms for visualizing directed acylic graphs

#19
post #13
post #2

The numbers in the circles are not neatly centered. They're a little off. Fixing that (center them perfectly) would make them visually much more appealing.

That will involve some optical alignment considering the actual shapes of the glyphs? I imagine one would get this feeling of not perfectly aligned even when the center of the bounding box of the numbers coincide with the center of the circle.

Most text rendering systems can do this quite well automatically.

Re: D3-dag – Layout algorithms for visualizing directed acylic graphs

#20
post #18

All these graph layout algorithms should ideally be run on the backend. Most of these js libraries are missing the point in trying to run layout in Javascript on the frontend. If you have a huge graph, you can't view all of it at once anyways and you're viewing a subset of it any 1 moment. So the ideal library should be running the layout on the backend and the frontend should be plain dummy, simply showing each grap…

Yep, that's how we architected Graphistry, and then some. GPUs frontend for rendering, GPUs backend for layout, analytics, etc.

Also agreed on subsets. About 1-10M nodes can still work in the frontend (and we're pushing upper end of that). But around 100K-1M nodes, more about seamless & interactive abstractions... and reinforces why integration w/ smart backend matters.

Post reply on HN