It's a bit confusing. Dot apparently is both the language name [1] for the Graphviz syntax, and one of the layout engines [2], possibly with different capitalizations.
I’m not sure how far you can push the generality of the iongraph algorithm. My gut is that it could be made to work somewhat well for any control flow graph with reducible control flow, but I expect there would be many complications.
This is a cool example of how specializing a generic algorithm to a specific subspace can yield much better results. This is quite often the case in my experience, but we often don't bother utilizing properties that are specific to our problem space, and just apply the generic algorithm out of convenience (and because it is often good enough)
I wrote my thesis on this! Application-specific system design can get you orders of magnitude performance improvement, as well as better scalability/fault tolerance properties. I focused on graph analytics, but it's reasonable to think it applies more broadly.
Definitely true that application-specific design is often not worth the investment though. Chasing that 1000x improvement can easily cost you a year or two.
Came here to say this, but with caveats. The particular domain has extra properties that allow their "stupider" algorithm to work better in their case. But a general graph drawing system has to deal with the inherent generality of the domain.
Usually there is a good middle ground: heuristic analysis of the input to see if it fits well with special-case "stupid and fast" algorithms, and sophisticated optimizations that are the fallback and work for everything and come with guarantees.
This is a great write up and thank you to the author! Just a note that graphviz dot is not purely Sugiyama’s, there is a paper on the site that details the actual implementation.
Also judging from the final two images (dot vs iongraph for the same large graph) it’s clear that dot is optimized for minimal area where iongraph does not. That’s the trade off. The author claims one is more easy to navigate than the other, I think that’s debatable.
Ultimately I found that visualizing large graphs is rarely helpful in practice; they can certainly look nice for some well defined graphs, but I rarely saw well defined graphs in the wild. Ymmv but maybe some would agree?
Visualizing large graphs is a "tarpit idea," one that initially seems appealing but never succeeds in practice.
Fundamentally, the problem is that visual aids can only really represent a few dozen things before they become as complicated as the thing you were trying to understand in the first place.
And when analyzing messy node diagrams, it’s not just the nodes we’re trying to visualize, but the lines connecting the nodes (the “edges”). We can only visualize a few dozen of those, and that typically means we can visualize only a handful of nodes at a time.
Visualization only works in trivial examples where you don’t need it; it fails in complex environments where you need it the most.
I agree that we haven’t gained much yet from looking at large graphs. Usually we can reduce any problem of interest to something small. Still, Graphviz produces very ugly results even for small graphs, whereas this is where iongraph shines.
To be clear, what I think makes the latter graph more readable is particularly that the wires are easier to follow. Yes, it’s subjective, but backed up by my own personal experience. Long term I think we can add more interactive features to help us in such cases, e.g. search and dimming irrelevant wires.
"Ultimately I found that visualizing large graphs is rarely helpful in practice; they can certainly look nice for some well defined graphs, but I rarely saw well defined graphs in the wild."
Since writing that I'm finding my frustration at the inability of diagrams to link out or be linked into is growing. In hindsight it seems a super obvious way of using diagrams in a useful manner and nothing supports it worth a crap, even things that really ought to like Mermaid (which permits out links in text but holds it at arm's length (requiring you to set the diagram to "unsafe"[1]) and as near I can tell in a quick search never mentions this as a thing you can do in its docs, and still has no particular support I can find for linking in to a graph). This has turned into a "can't unsee" for me.
(Obviously I have not used every diagramming solution ever, so maybe there is something out there that supports linking in and/or out, and I'd love to hear about it... however, bear in mind I'm looking for what you might call "first class" support, that is, a feature clearly considered important in the design phase of the project, not the sort of accidental-combination-of-features accidental support that Mermaid half has, if you flip some obscure settings to "lower security" somewhere.)
Yep, agreed. CMake does deps graphviz (been there), that is better than nothing. But big diagrams need support for exploding subdiagrams and going back.
For those who are interested, the Will Evans course on graph drawing [1] covers a lot of cool graph drawing algorithms. Graph drawing is very interesting and many applications get it wrong. I once contributed [2] some small bugfixes to the Dot lexer for the Open Graph Drawing Framework, which has fast implementations of some amazing graph drawing algorithms, and my experience is that the OGDF draws graphs vastly better than the various algorithms in GraphViz (fewer crossings, faster, etc).
The greatest thing about Graphviz is indeed the dot language. A nice thing about using dot is that the graph definition is *portable among all applications that support dot*.
Dot is such a simple and readable format (particularly if using the basic features). Thus, it can make a ton of sense to define graphs in strict dot, even if you will be rendering with another tool than Graphviz.
These days, there are other popular options, too -- Mermaid, etc, as TFA indicates. Nonetheless, Graphviz/dot will remain for the long haul, IMO, because dot is so, so good.
So, you need Graphviz for its syntax definitions primarily, and because it is a standard that could be recognized/run anywhere.
I have struggled with code to diagram tools for a while [mermaid and graphviz], and usually return to figjam when I need the readabilty and aesthetics.
graph-viz is MASSIVE and a binary. mermaid requires the browser's svg rendering system to work. I just need something that builds diagrams from description easily ...
The problem with all these tools is that any diagram becomes unreadable past a certain number of nodes. So we need a higher amount of control over the compromise that is inherent in these scenarios. The approach taken by the author is a very good step in this direction and hopefully others will follow.
I used mermaid for https://basisrobotics.tech/2024/11/24/basis-robot-02-softwar... (autogenerated) and it worked out pretty well, but notably I wasn't trying to handle loops. There have to be mermaid to png renderers out there. Beyond that, I view svg/html output as a huge advantage - I can restyle it and it's copyable.
>graph-viz is MASSIVE and a binary. mermaid requires the browser's svg rendering system to work.
I succeeded to use resvg-js [1] with dagre/graphlib [2] to render graphs. resvg-js uses a 4 MB node library to render SVGs. dagre is used by mermaid for graph layout (for some of the diagram types). if you disable loading system fonts in resvg-js it just takes milliseconds to render the SVG.
I know that mermaid is well-known and very useful, but I don't like the code quality (especially consistency) and the bloat of dependencies. Last time I went through the code I assessed it requires significant refactorings to make it work with resvg-js, i.e. server-side graph layout and rendering.
There is also nomnoml [1], which is so great, it should deserve at least the same amount of attention as mermaid. the nomnoml codebase is a joy to read. the author even converted the dagre/graphlib codebase to typescript [4].
Edit: One of the refactorings to make mermaid work with resvg-js is related to measuring svg text width. It's needed to determine the width of the graph node boxes. mermaid needs to be able to also use `resvg.getBBox()` to make it work with server-side rendering.
Surprised by your comment, I took a gander at graphviz; it's about a quarter of a million lines of code if you discount lib/sparse/color_palette.c and lib/edgepaint/lab_gamut.c, which are hundreds of thousands of lines of data values. This is much more than I expected.
If you want something that builds diagrams from textual descriptions, you might want to check out TikZ, which includes a subset of graphviz but also lets you draw anything you want. See https://en.wikipedia.org/wiki/PGF/TikZ. On the other hand, you won't have the rapid visual feedback you get with WYSIWYG drawing editors like FigJam.
This is a concept I'm working around with Microdiagram (microdiagram.com) prototype.
i.e. having a general purpose diagram/graph layout is hellishly difficult, but most of the diagrams/charts follow much simpler rules, thus it's much easier to have N languages, each for 1 type of diagram, than 1 language for N types of diagrams.
While I fully support your efforts to make better tooling, UML is the poster child for this.
I highly encourage people working in this space to revisit those lessons.
Obviously if you find a new way to work around the limitations please run with it.
But limited scope, and targeted simplifications is the only way I have found, over application by trying to describe everything almost always ends up being more harmful in my experience.
I would love to see this evolve into a more general purpose control flow graph viewer - pretty much any language implementation would find it a great debugging tool. it's probably most of the way there already.
this tool works by replacing the "general purpose" algorithm by specializing it, which made it less general purpose but simpler and more efficient ... and now there's the request to make it more general purpose.
(it's a joke! and the joke is that those are two different general purpose. but still.)
Nice work! The examples look better than the Graphviz output, indeed. This is a good example of how you can always beat a long-developed, generic tool by specializing for a much narrower use case.
this article is confusing, it appears to conflate graphviz (an umbrella term/tool that collects a set of layout engines and output formats) with both dot (a specific layout engine) and sstangl/iongraph (a specific tool that transforms a particular SSA/AST input format to a specific dot output format)
it also seems to conflate how a DAG is expressed, with how that expression is rendered
I feel like going to the source of an algorithm/implementation is a super power, as illustrated by this example.
Having used Graphviz for fairly complex visualizations I was initially shocked that someone would rewrite it themselves. Then I saw the breakdown of the algorithm and realized it may not be as complicated as I first thought.
All that being said, as a general rule it is hard to know what the hidden complexities may be until you are finished implementing the algorithm.
This is great. I've been trying to generate diagrams for HDL hierarchies and neither Graphviz nor ELK can do a remotely good job. In fact I've never got good results from Graphviz for any graphs over a handful of nodes. I think it just isn't actually very good. But it has such huge mindshare even if there was a better option I wouldn't be able to find it.
Layout is one of those things humans do so easily and intuitively, yet you couldn't write an easy algorithm for it. I wonder if there's potential to use gen ai to achieve human like results. Anyone has any thoughts on feasibility and complexity of such an approach?
I dabbled in this area, there are poster layout generation attempts that use gen ai to come up with an initial layout plan, and even feed the visualization back into the llm for iterative fine-tuning.
I was intrigued, but couldn't make it work reliably. Perhaps I forgot to add "make it look nice" to my prompts.
I think the hard part is more defining the different types of visually pleasing layouts that you want to support. What to align to what, what metrics to minimize, etc.
There is no single layout definition that looks good for all applications. What looks good for one type of graph data (flow charts, org charts, ASTs, family trees, etc, etc) may not look good for another.
Once you've reduced a desired type of layout to a set of layout rules, then I don't think implementing it is the bottleneck, and it seems this part could even be automated if wanted (e.g. evolve layout to best meet constraints).
This is great! There are surprisingly few tools that actually output anything nice when it feels like such a doable problem.
One small improvement they could probably make is the ability to rearrange outputs at the bottom to reduce crossings. Just from the very first example it seems flipping the 0 and 1 outputs on the bottom graph would be nicer.
For anyone else interested in this general area, Steve Ruiz and Lu Wilson from tldraw often tweet a lot of fun nitty gritty edge cases in graph drawing.
Resist this temptation. It is better for the true and false branches to always appear in the same order than to permute things to avoid edge crossings.
We looked at using Graphviz, but the copyleft nature of Graphviz license (Eclipse Public License) means that this will never be allowed in our company's software.
Interesting. The wiki says: "The Eclipse Public License is designed to be a business-friendly free software license, and features weaker copyleft provisions than licenses such as the GNU General Public License (GPL)."
Wonder how it compares with elkjs? I had written a few things that wrapped dot, which felt clunky, but have since had good success writing react components that use elkjs. Elkjs has a stupid amount of configuration options, some of which aren't very clearly documented, but I've been able to get decent output for use cases like argument mapping and choose-your-own-adventure maps.
If you can get the AST output into a text file, then it should be easy to convert it to the DOT input that GraphViz takes, which at heart is just a list of node connections (A -> B).
D2 "should" handle most cases OP was annoyed about. Its written in Go, so its really fast too. I never had to wait for it to finish, but that said i never produced huge diagrams that i could imagine a compiler would.
One of the nice things about this work is that by assuming the environment is a web client, it supports some basic interactive exploration, and offloads a lot of bothersome rendering problems.
Also, by focusing on control flow graphs, the proposed method does a better job with domain-specific layout. Apparently CFG visualization and exploration is a current topic; e.g. CFGExplorer. Probably Graphviz some users would benefit if it incorporated CFG-friendly level assignment as an option.
There's already machinery in Graphviz to support polylines instead of splines, and to control edge ordering, but it is not well tested or documented. It seems tempting to incorporate an edge routing algorithm of Brandes and Kopf, based on long vertical runs with at most 2 bends per edge. This seems close to a master's degree worth of work to understand and implement.
Graphviz started almost 40 years ago, is only supported by a few (one or two?) 2nd-generation volunteers with no 3rd generation on the scene yet. Over the years we've had plenty of our own disdainful "What is all this junk" moments, about our own code and other people's (c.f. various xkcd comics), but sometimes a better perspective is asking "What is being optimized that led to some team choosing or ending up at this point in the design space". Generally, the market is addicted to features.
It is a little dismaying to see the relatively slow progress in the broad field of declarative 2d diagramming. Given the way the pendulum has swung so hard back toward language based methods and away from using interaction to do everything, you'd think there would be a bigger payoff now for doing the work. Unfortuantely tool-making has always been a tough market. The customers are generally smart, demanding, and work in cost centers so don't have generous budgets.
The part that is timing out is actually the JS interpreter, not the graph viewer. It’s a total hack to get SpiderMonkey running on the page at all.
The full Frankenstein stack is: SpiderMonkey compiled in arm emulation mode, to a WASI 0.1 module, adapted to a WASI 0.2 component, transpiled to the web with jco, running in some random WASI shim.
We do this because the JS runtime needs inline caches to be filled out before optimization, which requires an JIT and actual execution of machine code. Otherwise you just get a graph full of Unreachable. Frankly I’m amazed it works at all.
It used to be a that the barrier of entry of creating a new tool was high - so we had to use popular pieces of software, often stretching them, or writing plugins (that had their own constraints).
Now it is often easier to write from scratch a new piece of software, for which with have full control.
We can stand on the shoulders of giants - not just "a giant".
To me, this article demonstrated the value of knowing your domain and its particular constraints, as well as a good understanding of prior art. Together with the only 1000 line demo it took to produce (which I suppose could have been aided by an LLM), I did not finish reading with any specific appreciation for AI.
zvr|4 months ago
Graphviz is a visualization framework and it includes many layout engines, implementing different algorithms: dot, neato, fdp, sfdp, circo, twopi, ...
It would be great if this new custom algorithm were to be contributed to Graphviz.
fulafel|4 months ago
[1] https://graphviz.org/doc/info/lang.html [2] https://graphviz.org/docs/layouts/dot/
bvisness|4 months ago
rurban|4 months ago
ctenb|4 months ago
lasfter|4 months ago
Definitely true that application-specific design is often not worth the investment though. Chasing that 1000x improvement can easily cost you a year or two.
j2kun|4 months ago
Usually there is a good middle ground: heuristic analysis of the input to see if it fits well with special-case "stupid and fast" algorithms, and sophisticated optimizations that are the fallback and work for everything and come with guarantees.
le-mark|4 months ago
Also judging from the final two images (dot vs iongraph for the same large graph) it’s clear that dot is optimized for minimal area where iongraph does not. That’s the trade off. The author claims one is more easy to navigate than the other, I think that’s debatable.
Ultimately I found that visualizing large graphs is rarely helpful in practice; they can certainly look nice for some well defined graphs, but I rarely saw well defined graphs in the wild. Ymmv but maybe some would agree?
dfabulich|4 months ago
Fundamentally, the problem is that visual aids can only really represent a few dozen things before they become as complicated as the thing you were trying to understand in the first place.
And when analyzing messy node diagrams, it’s not just the nodes we’re trying to visualize, but the lines connecting the nodes (the “edges”). We can only visualize a few dozen of those, and that typically means we can visualize only a handful of nodes at a time.
Visualization only works in trivial examples where you don’t need it; it fails in complex environments where you need it the most.
bvisness|4 months ago
To be clear, what I think makes the latter graph more readable is particularly that the wires are easier to follow. Yes, it’s subjective, but backed up by my own personal experience. Long term I think we can add more interactive features to help us in such cases, e.g. search and dimming irrelevant wires.
jerf|4 months ago
Yes, I'm with you: https://jerf.org/iri/post/2025/on_layers_and_boxes_and_lines...
Since writing that I'm finding my frustration at the inability of diagrams to link out or be linked into is growing. In hindsight it seems a super obvious way of using diagrams in a useful manner and nothing supports it worth a crap, even things that really ought to like Mermaid (which permits out links in text but holds it at arm's length (requiring you to set the diagram to "unsafe"[1]) and as near I can tell in a quick search never mentions this as a thing you can do in its docs, and still has no particular support I can find for linking in to a graph). This has turned into a "can't unsee" for me.
(Obviously I have not used every diagramming solution ever, so maybe there is something out there that supports linking in and/or out, and I'd love to hear about it... however, bear in mind I'm looking for what you might call "first class" support, that is, a feature clearly considered important in the design phase of the project, not the sort of accidental-combination-of-features accidental support that Mermaid half has, if you flip some obscure settings to "lower security" somewhere.)
[1]: https://stackoverflow.com/questions/41960529/how-to-add-a-li...
jesuslop|4 months ago
lexh|4 months ago
I wonder if any of these techniques turn up in whatever the magic sauce is in D2’s TALA layout engine, which is in a league of its own IMO.
https://d2lang.com/examples/tala/
dllu|4 months ago
[1] https://www.cs.ubc.ca/~will/536E/
[2] https://github.com/ogdf/ogdf/pulls?q=is%3Apr%20author%3Adllu...
realityfactchex|4 months ago
Dot is such a simple and readable format (particularly if using the basic features). Thus, it can make a ton of sense to define graphs in strict dot, even if you will be rendering with another tool than Graphviz.
These days, there are other popular options, too -- Mermaid, etc, as TFA indicates. Nonetheless, Graphviz/dot will remain for the long haul, IMO, because dot is so, so good.
So, you need Graphviz for its syntax definitions primarily, and because it is a standard that could be recognized/run anywhere.
bvisness|4 months ago
nirava|4 months ago
I have struggled with code to diagram tools for a while [mermaid and graphviz], and usually return to figjam when I need the readabilty and aesthetics.
graph-viz is MASSIVE and a binary. mermaid requires the browser's svg rendering system to work. I just need something that builds diagrams from description easily ...
benterix|4 months ago
a_t48|4 months ago
rapnie|4 months ago
https://news.ycombinator.com/item?id=45707539
tauchunfall|4 months ago
I succeeded to use resvg-js [1] with dagre/graphlib [2] to render graphs. resvg-js uses a 4 MB node library to render SVGs. dagre is used by mermaid for graph layout (for some of the diagram types). if you disable loading system fonts in resvg-js it just takes milliseconds to render the SVG.
I know that mermaid is well-known and very useful, but I don't like the code quality (especially consistency) and the bloat of dependencies. Last time I went through the code I assessed it requires significant refactorings to make it work with resvg-js, i.e. server-side graph layout and rendering.
There is also nomnoml [1], which is so great, it should deserve at least the same amount of attention as mermaid. the nomnoml codebase is a joy to read. the author even converted the dagre/graphlib codebase to typescript [4].
[1] https://github.com/thx/resvg-js [2] https://github.com/dagrejs/dagre [3] https://github.com/skanaar/nomnoml [4] https://github.com/skanaar/graphre
---
Edit: One of the refactorings to make mermaid work with resvg-js is related to measuring svg text width. It's needed to determine the width of the graph node boxes. mermaid needs to be able to also use `resvg.getBBox()` to make it work with server-side rendering.
kragen|4 months ago
If you want something that builds diagrams from textual descriptions, you might want to check out TikZ, which includes a subset of graphviz but also lets you draw anything you want. See https://en.wikipedia.org/wiki/PGF/TikZ. On the other hand, you won't have the rapid visual feedback you get with WYSIWYG drawing editors like FigJam.
aqula|4 months ago
https://marketplace.visualstudio.com/items?itemName=infragra...
xlii|4 months ago
i.e. having a general purpose diagram/graph layout is hellishly difficult, but most of the diagrams/charts follow much simpler rules, thus it's much easier to have N languages, each for 1 type of diagram, than 1 language for N types of diagrams.
nyrikki|4 months ago
I highly encourage people working in this space to revisit those lessons.
Obviously if you find a new way to work around the limitations please run with it.
But limited scope, and targeted simplifications is the only way I have found, over application by trying to describe everything almost always ends up being more harmful in my experience.
JohnKemeny|4 months ago
zem|4 months ago
stefs|4 months ago
(it's a joke! and the joke is that those are two different general purpose. but still.)
thw_9a83c|4 months ago
kiitos|4 months ago
it also seems to conflate how a DAG is expressed, with how that expression is rendered
strange
colelyman|4 months ago
Having used Graphviz for fairly complex visualizations I was initially shocked that someone would rewrite it themselves. Then I saw the breakdown of the algorithm and realized it may not be as complicated as I first thought.
All that being said, as a general rule it is hard to know what the hidden complexities may be until you are finished implementing the algorithm.
IshKebab|4 months ago
aqula|4 months ago
pestaa|4 months ago
I was intrigued, but couldn't make it work reliably. Perhaps I forgot to add "make it look nice" to my prompts.
https://arxiv.org/abs/2412.04237v3
https://haoyuchen.com/POSTA
https://github.com/microsoft/LayoutGeneration/blob/main/Layo...
HarHarVeryFunny|4 months ago
There is no single layout definition that looks good for all applications. What looks good for one type of graph data (flow charts, org charts, ASTs, family trees, etc, etc) may not look good for another.
Once you've reduced a desired type of layout to a set of layout rules, then I don't think implementing it is the bottleneck, and it seems this part could even be automated if wanted (e.g. evolve layout to best meet constraints).
eisbaw|4 months ago
OisinMoran|4 months ago
One small improvement they could probably make is the ability to rearrange outputs at the bottom to reduce crossings. Just from the very first example it seems flipping the 0 and 1 outputs on the bottom graph would be nicer.
For anyone else interested in this general area, Steve Ruiz and Lu Wilson from tldraw often tweet a lot of fun nitty gritty edge cases in graph drawing.
bvisness|4 months ago
rs186|4 months ago
benterix|4 months ago
saagarjha|4 months ago
anotheryou|4 months ago
I love how bitwig solved it: gravity, color coding, stiffness, directionality (ins on the left, outs on the right).
https://polarity.me/img/bitwig-course-02-whatisthegrid-3.jpg
tunesmith|4 months ago
frumiousirc|4 months ago
1. Make graphs from Clang's AST.
2. Invent some style flourish to help follow an edge that becomes part of a bundle of many edges.
HarHarVeryFunny|4 months ago
phplovesong|4 months ago
hawk_|4 months ago
unknown|4 months ago
[deleted]
graphviz|4 months ago
Also, by focusing on control flow graphs, the proposed method does a better job with domain-specific layout. Apparently CFG visualization and exploration is a current topic; e.g. CFGExplorer. Probably Graphviz some users would benefit if it incorporated CFG-friendly level assignment as an option.
There's already machinery in Graphviz to support polylines instead of splines, and to control edge ordering, but it is not well tested or documented. It seems tempting to incorporate an edge routing algorithm of Brandes and Kopf, based on long vertical runs with at most 2 bends per edge. This seems close to a master's degree worth of work to understand and implement.
Graphviz started almost 40 years ago, is only supported by a few (one or two?) 2nd-generation volunteers with no 3rd generation on the scene yet. Over the years we've had plenty of our own disdainful "What is all this junk" moments, about our own code and other people's (c.f. various xkcd comics), but sometimes a better perspective is asking "What is being optimized that led to some team choosing or ending up at this point in the design space". Generally, the market is addicted to features.
It is a little dismaying to see the relatively slow progress in the broad field of declarative 2d diagramming. Given the way the pendulum has swung so hard back toward language based methods and away from using interaction to do everything, you'd think there would be a bigger payoff now for doing the work. Unfortuantely tool-making has always been a tough market. The customers are generally smart, demanding, and work in cost centers so don't have generous budgets.
kragen|4 months ago
ynniv|4 months ago
https://github.com/eclipse-elk/elk
OhMeadhbh|4 months ago
Western0|4 months ago
JEFFREYBURKE|4 months ago
[deleted]
JEFFREYBURKE|4 months ago
[deleted]
syahlanahda|4 months ago
[deleted]
worthless-trash|4 months ago
JohnKemeny|4 months ago
bvisness|4 months ago
The full Frankenstein stack is: SpiderMonkey compiled in arm emulation mode, to a WASI 0.1 module, adapted to a WASI 0.2 component, transpiled to the web with jco, running in some random WASI shim.
We do this because the JS runtime needs inline caches to be filled out before optimization, which requires an JIT and actual execution of machine code. Otherwise you just get a graph full of Unreachable. Frankly I’m amazed it works at all.
rag-hav|4 months ago
stared|4 months ago
It used to be a that the barrier of entry of creating a new tool was high - so we had to use popular pieces of software, often stretching them, or writing plugins (that had their own constraints).
Now it is often easier to write from scratch a new piece of software, for which with have full control.
We can stand on the shoulders of giants - not just "a giant".
jrrrp|4 months ago
benterix|4 months ago