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've used GraphViz/Dot (I call `dot` in my terminal, but the package to install is `graphviz`) for probably two decades at this point, and what is what is still not clear to me, kind of like the whole imagemagick/convert thing which is similar, at least to someone on the outside.
Not sure why they can't come up with new names, use those, then when you invoke the program in the terminal, call the binary the same thing, instead of mucking about with calling everything differently, except some things, that share names.
This is exactly what they have done. You can call "dot" and it runs the dot layout engine, but you can also run "neato", "sfdp" or any other -- with the same input.
The "graphviz" package installs all these executables.
I can see how you got that impression and don’t fault you for it in the slightest, but that’s not accurate.
It’s not the language name for all Graphviz syntax; it’s only the syntax for renderings made with the dot engine. Each engine has its own DSL, basically.
Does it? There are slightly different DSLs for directed and non-directed graphs, some features only work with some output formats, but AFAIK, everything in the DSL in independent of the layout engine.
And if I look in my /usr/bin, I see that neato is just symlinked to dot. It's pulling the usual trick of one executable that behaves slightly differently depending on the invocation name.
Looking at the docs again with fresh eyes, I think you and fulafel are on the money.
The specific engine syntaxes are by & large mutually incompatible, but DOT does seem to be the label used for the overall lang as well as the dot-engine-compatible dialect.
Various tools use tool-specific graph attributes. For example, "rank" and "minlen" mean something to the hierarchical or layered graph layout tool (dot) but not to other layout tools. "size" and "label" are the same in all the layout tools. They all use the same underlying graph representation library with a parser generated by yacc or bison.
The documentation includes a big table of attributes that graphviz tools recognize.
With the availability of LLMs, there is better automated support now to find features that are needed. Just imagining here, but "make the layout fill the available space" or "make all the nodes look like points with associated text labels" (not sure if that even works but it should).
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.
To get more precise, we benefit from knowing the nesting depth of each block. This plus reducible control flow is enough to reliably find loops. We also know exactly which edges are loop backedges; it’s easiest when these are explicitly annotated but perhaps it would be possible to derive that info from other loop info. (In Ion we have a dedicated “backedge block” per loop, which makes it obvious what we should do, but which other compilers likely wouldn’t have.)
There are also a bunch more available information channels that this doesn’t use that could communicate more information. Color, shape, pattern line type, “backdrops”/groups could all be implemented to provide additional visual clarity on any range of parameters you might care about.
I used to use the dcc application Nuke and it had some very complex graphs but the different nodes were all color coded so zooming out you could get a good idea of what was happening where just from the average color of a section.
It didn’t have an auto layout algo as good as this though.
What I really like about the article is the reflection on the limits of optimization. Optimization gets you mostly OK results most of the time, but there will always be pathological cases where optimization gives you bad results, and there’s often room for drastic improvements of you’re allowed to make stronger assumptions.
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.
This is my problem with node based editors, the one I am most familiar with being blenders shader editor. I mean, sure, I guess it represents the internal structure. But it always feels so messy. Sometimes I wish blender would just let me work with a netlist.
There's a threshold, of both user ability and scale of 'problem'
I mostly agree with you dfabulich - the repeated efforts to create node/pipeline tools "visual programming languages" are not built for us, and feel redundant.
But I took issue with "where you don't need it" as this is very much dependent on who "you" is.
I would go further. The fundamental problem is the idea that there is a fundamentally correct representation of something. This actually goes further than even the visualization of the graph. Symbolic representations have the same trap.
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.)
> There are three basic types of “boxes and lines” (as I derisively refer to them) diagrams:
the point of a boxes-and-lines diagram is to express relationships between components at a single layer/level of abstraction
the best metric for the "quality" of a diagram isn't the number of boxes, rather it's the number of edge-crossings, where >0 is a pretty reliable signal that either (a) the diagram is trying to show too much, or (b) the architecture is sub-optimal
any non-trivial system will always require multiple boxes-and-lines diagrams to be accurately described, one per abstraction-layer
and not really sure that linking between diagram and code is a core requirement, diagrams will generally include identifiers that are unambiguously grep-able, i guess...
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.
Mermaid is great in its niche, and being web-first has been its greatest asset. But that is also a great frustration because anytime I try to do anything out of the web-world with mermaid, it becomes a massive PITA thanks to needing a full headless browser.
I used graphviz to generate graphs for code structures, and that worked out great.
>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.
The Piano chart on prototype is an example, that's for discussing piano keys and chords on basic level.
I already implemented (in other prototype) diagram for event calculus (i.e. consideration of event stream through addition of new events like rollback, modify etc.)
On paper I have designs for point-in-time designs, scenario divergence and also some fun ones like a bingo card template. Diagrams are one thing, but there's also a design for collaboration and play-replay capabilities.
That being said, that's only a design right now with a simple prototype on the website :)
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.)
Language developers really do struggle with debugging our data-structures since they are often both circular and complex compared to many other applications, I wrote yet-another-UI tool for inspecting code back when I was doing my thesis work.
Maybe I should brush it off (and make it general... ), it would give you a source-code view and navigating the source-text you would be shown compiler nodes related to the lines/statements.
It was almost the only way to make sense of it since I was often generating multiple paths per statement (It was a lossy type-inference system so previous type branchings could lead to multiple subsequent code-paths through each statement and expression).
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)."
Well, it's just they think it's business-friendly.
From EPL:
> If a Contributor Distributes the Program in any form, then: a) the Program must also be made available as Source Code, in accordance with section 3.2 ...
Except in startups that really embrace the idea of open source, no "serious" company will offer any portion of their source code under EPL license, even if that's just the modified/derived part of it. Not a chance.
For most companies, in reality, there are only two types of licenses -- copyleft and permissive, no middle ground. You either don't touch it with a 10 foot pole or do whatever you want as long as you copy and paste the attributions.
So this basically depends on how you intend to use. All big corporations use tons of copyleft software, starting with Linux. But if your aim is to take a piece of software, modify it, and don't share your modifications, and this scenario makes you not to choose this particular project, then yes, the license is working as expected. Whether the net benefit of this is positive or not is another question.
There are a pretty large number of "serious" companies that distribute code under the GNU GPL, which has similar but more stringent copyleft terms. IBM, for example, which also originated the Eclipse Public License, and TI, and ARM, and Apple. Almost every microcontroller vendor uses GCC.
I meant "product code" mostly, and of course you could say WebKit is part of a product and you'll be correct. My point is that it's the exception, not the norm. (Using "no company" was wrong on my end)
True, and in fact I am aware that other teams look for paid solutions where graphs power the core features of their products. For us, it is a small feature, so we were looking for the "least trouble" path.
I don't know enough about all those other libraries and their licenses, but I do know that as long as we don't ship those libraries, especially modified versions, it's likely ok (of course that's simplified). Some internal tooling depends on GNU tools but we are just users. For things like glibc, it's just a standard system library, so linking with it is not a problem. (I am sure legal has looked at this.)
But GPL/LGPL software is definitely the minority of software we use in any way. Basically they need to be avoided as much as possible.
whatever, it's not the only graphics library out there. These days, almost for every software with copyleft license there is a permissive alternative, perhaps with the notable exception of Linux kernel.
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).
The issue is to make sense of the incredibly detailed AST to answer various questions about the code base. For example, how to make an information flow graph that shows what functions read and write what variables in a set of C++ classes.
I had tried this with the previous versions of sonnet and gemini pro. Sonnet's context, back then, could not hold the full source I was working on. Reducing the context did allow it produce a graph. Both LLMs produced graphs with enough omissions and errors to make the result not useful. In the end, I wrote an interpreter based on libclang to provide the semantics I needed for my particular case. That was not trivial for me (I have decades of experience with s/w dev, working with graphs, etc - but not compiler development). And I used LLM's help to do the development. The new type of semantics would require hard-coding new AST interpreter and graph construction. Repeating that all today with the better LLMs and after more practice driving them might produce something with less effort / more flexibility.
In any case, this experience gave me a new appreciation for compiler developers!
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.
But based on my experience with multiple project, both current frameworks and AI changed the game. I used to much more reply on existing software and cursing that they don't do what I want - as the time to create a personalized tool was simply much to afford. Now often it is quicker to create a personalized tool than fight with existing one.
To be more accurate, the comparison is not with Graphviz, but with dot(1).
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.
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.
[1] https://graphviz.org/doc/info/lang.html [2] https://graphviz.org/docs/layouts/dot/
I've used GraphViz/Dot (I call `dot` in my terminal, but the package to install is `graphviz`) for probably two decades at this point, and what is what is still not clear to me, kind of like the whole imagemagick/convert thing which is similar, at least to someone on the outside.
Not sure why they can't come up with new names, use those, then when you invoke the program in the terminal, call the binary the same thing, instead of mucking about with calling everything differently, except some things, that share names.
> Not sure why they can't ...
This is exactly what they have done. You can call "dot" and it runs the dot layout engine, but you can also run "neato", "sfdp" or any other -- with the same input.
The "graphviz" package installs all these executables.
At least Imagemagick came to their senses and renamed their command to magick (with convert still aliased for BC).
I can see how you got that impression and don’t fault you for it in the slightest, but that’s not accurate.
It’s not the language name for all Graphviz syntax; it’s only the syntax for renderings made with the dot engine. Each engine has its own DSL, basically.
> Each engine has its own DSL, basically.
Does it? There are slightly different DSLs for directed and non-directed graphs, some features only work with some output formats, but AFAIK, everything in the DSL in independent of the layout engine.
You can also set:
in a dot file, call dot, and it will use the neato layout engine.(See https://graphviz.org/docs/attrs/layout/)
And if I look in my /usr/bin, I see that neato is just symlinked to dot. It's pulling the usual trick of one executable that behaves slightly differently depending on the invocation name.
Looking at the docs again with fresh eyes, I think you and fulafel are on the money.
The specific engine syntaxes are by & large mutually incompatible, but DOT does seem to be the label used for the overall lang as well as the dot-engine-compatible dialect.
Various tools use tool-specific graph attributes. For example, "rank" and "minlen" mean something to the hierarchical or layered graph layout tool (dot) but not to other layout tools. "size" and "label" are the same in all the layout tools. They all use the same underlying graph representation library with a parser generated by yacc or bison.
The documentation includes a big table of attributes that graphviz tools recognize.
With the availability of LLMs, there is better automated support now to find features that are needed. Just imagining here, but "make the layout fill the available space" or "make all the nodes look like points with associated text labels" (not sure if that even works but it should).
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.
To get more precise, we benefit from knowing the nesting depth of each block. This plus reducible control flow is enough to reliably find loops. We also know exactly which edges are loop backedges; it’s easiest when these are explicitly annotated but perhaps it would be possible to derive that info from other loop info. (In Ion we have a dedicated “backedge block” per loop, which makes it obvious what we should do, but which other compilers likely wouldn’t have.)
There are also a bunch more available information channels that this doesn’t use that could communicate more information. Color, shape, pattern line type, “backdrops”/groups could all be implemented to provide additional visual clarity on any range of parameters you might care about.
I used to use the dcc application Nuke and it had some very complex graphs but the different nodes were all color coded so zooming out you could get a good idea of what was happening where just from the average color of a section.
It didn’t have an auto layout algo as good as this though.
What I really like about the article is the reflection on the limits of optimization. Optimization gets you mostly OK results most of the time, but there will always be pathological cases where optimization gives you bad results, and there’s often room for drastic improvements of you’re allowed to make stronger assumptions.
Yes, that would be great. Iongraph is MPL, graphviz is EPL. But Iongraph is Javascript anyway, so you would need to use Claude to translate it to C
Why would you need Claude for that?
Everyone knows it is impossible to translate 1000 lines of JS to C in a reasonable amount of time. I mean, 1000 lines is kind of a lot, you know?
"Need" is a bad word ... and ymmv
Kimi is also good. New habits, you know
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.
Can you please link to your thesis? This sounds very interesting.
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.
That's how all application-specific specializations work though, take advantage of domain properties that make you need a less generic algorithm.
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.
This is my problem with node based editors, the one I am most familiar with being blenders shader editor. I mean, sure, I guess it represents the internal structure. But it always feels so messy. Sometimes I wish blender would just let me work with a netlist.
There's a threshold, of both user ability and scale of 'problem'
I mostly agree with you dfabulich - the repeated efforts to create node/pipeline tools "visual programming languages" are not built for us, and feel redundant.
But I took issue with "where you don't need it" as this is very much dependent on who "you" is.
I would go further. The fundamental problem is the idea that there is a fundamentally correct representation of something. This actually goes further than even the visualization of the graph. Symbolic representations have the same trap.
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.
I confess I found the graphs GraphViz made for me in https://taeric.github.io/many_sums.html oddly pretty. :D
"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."
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...
> There are three basic types of “boxes and lines” (as I derisively refer to them) diagrams:
the point of a boxes-and-lines diagram is to express relationships between components at a single layer/level of abstraction
the best metric for the "quality" of a diagram isn't the number of boxes, rather it's the number of edge-crossings, where >0 is a pretty reliable signal that either (a) the diagram is trying to show too much, or (b) the architecture is sub-optimal
any non-trivial system will always require multiple boxes-and-lines diagrams to be accurately described, one per abstraction-layer
and not really sure that linking between diagram and code is a core requirement, diagrams will generally include identifiers that are unambiguously grep-able, i guess...
Enterprise architect ($$) had that buried in the gui, and wondered for long if obsidian canvas could do the same, reports wanted.
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).
[1] https://www.cs.ubc.ca/~will/536E/
[2] https://github.com/ogdf/ogdf/pulls?q=is%3Apr%20author%3Adllu...
This is a great write up.
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/
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 love the status quo! My favorite thing about it is that it is the status quo."
anyone working on this space easily gets a +1!
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.
Mermaid is great in its niche, and being web-first has been its greatest asset. But that is also a great frustration because anytime I try to do anything out of the web-world with mermaid, it becomes a massive PITA thanks to needing a full headless browser.
I used graphviz to generate graphs for code structures, and that worked out great.
https://niravko.com/blog/visualize-cpp-data-structures#resul...
You might also check out D2, which had a recent run on the HN front page.
https://news.ycombinator.com/item?id=45707539
>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].
[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.
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.
I've had good results using ELK for a terraform diagram generator. You can see some samples here.
https://marketplace.visualstudio.com/items?itemName=infragra...
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.
Sounds intriguing. What is an example of a chart and its language that you have designed so far?
The Piano chart on prototype is an example, that's for discussing piano keys and chords on basic level.
I already implemented (in other prototype) diagram for event calculus (i.e. consideration of event stream through addition of new events like rollback, modify etc.)
On paper I have designs for point-in-time designs, scenario divergence and also some fun ones like a bingo card template. Diagrams are one thing, but there's also a design for collaboration and play-replay capabilities.
That being said, that's only a design right now with a simple prototype on the website :)
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.)
I do get the joke but it's a tad misplaced here.
Language developers really do struggle with debugging our data-structures since they are often both circular and complex compared to many other applications, I wrote yet-another-UI tool for inspecting code back when I was doing my thesis work.
Maybe I should brush it off (and make it general... ), it would give you a source-code view and navigating the source-text you would be shown compiler nodes related to the lines/statements.
It was almost the only way to make sense of it since I was often generating multiple paths per statement (It was a lossy type-inference system so previous type branchings could lead to multiple subsequent code-paths through each statement and expression).
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
strange
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.
https://arxiv.org/abs/2412.04237v3
https://haoyuchen.com/POSTA
https://github.com/microsoft/LayoutGeneration/blob/main/Layo...
Thanks for sharing. Although diagrams have a unique requirement that the boxes are inter-connected, and those connections must also look "nice".
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).
Wow, thank you very much. I like the graphviz dot language. I may translate this to Rust.
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)."
Well, it's just they think it's business-friendly.
From EPL:
> If a Contributor Distributes the Program in any form, then: a) the Program must also be made available as Source Code, in accordance with section 3.2 ...
Except in startups that really embrace the idea of open source, no "serious" company will offer any portion of their source code under EPL license, even if that's just the modified/derived part of it. Not a chance.
For most companies, in reality, there are only two types of licenses -- copyleft and permissive, no middle ground. You either don't touch it with a 10 foot pole or do whatever you want as long as you copy and paste the attributions.
So this basically depends on how you intend to use. All big corporations use tons of copyleft software, starting with Linux. But if your aim is to take a piece of software, modify it, and don't share your modifications, and this scenario makes you not to choose this particular project, then yes, the license is working as expected. Whether the net benefit of this is positive or not is another question.
There are a pretty large number of "serious" companies that distribute code under the GNU GPL, which has similar but more stringent copyleft terms. IBM, for example, which also originated the Eclipse Public License, and TI, and ARM, and Apple. Almost every microcontroller vendor uses GCC.
I meant "product code" mostly, and of course you could say WebKit is part of a product and you'll be correct. My point is that it's the exception, not the norm. (Using "no company" was wrong on my end)
Don't most companies seek a supported product, like yWorks or Tom Sawyer Software in the case of graph layout?
Isn't the EPL "weak copyleft", so LGPL-ish? Would companies raise similar issues about glibc and GNU libstdc++? Just curious.
True, and in fact I am aware that other teams look for paid solutions where graphs power the core features of their products. For us, it is a small feature, so we were looking for the "least trouble" path.
I don't know enough about all those other libraries and their licenses, but I do know that as long as we don't ship those libraries, especially modified versions, it's likely ok (of course that's simplified). Some internal tooling depends on GNU tools but we are just users. For things like glibc, it's just a standard system library, so linking with it is not a problem. (I am sure legal has looked at this.)
But GPL/LGPL software is definitely the minority of software we use in any way. Basically they need to be avoided as much as possible.
> if a Contributor Distributes
Doesn't this only apply to contributors and dev users?
I think it applies to anyone who distributes it; https://www.eclipse.org/legal/epl-2.0/ says:
Can't you buy an exception to the license?
Not my call.
Your loss I guess
whatever, it's not the only graphics library out there. These days, almost for every software with copyleft license there is a permissive alternative, perhaps with the notable exception of Linux kernel.
looking at the spagetti: neither is readable, but I'd say wonky graphviz wins because you have a chance following some of the lines.
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
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.
Looks nice. Two things on my wish list:
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.
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).
"clang -Xclang -ast-dump=json" will take you partway there.
The issue is to make sense of the incredibly detailed AST to answer various questions about the code base. For example, how to make an information flow graph that shows what functions read and write what variables in a set of C++ classes.
This sounds like it might be a good use case for one of the LLM coding tools.
A pure AST wouldn't even have that information - it'd have the syntax, but not the semantics.
I had tried this with the previous versions of sonnet and gemini pro. Sonnet's context, back then, could not hold the full source I was working on. Reducing the context did allow it produce a graph. Both LLMs produced graphs with enough omissions and errors to make the result not useful. In the end, I wrote an interpreter based on libclang to provide the semantics I needed for my particular case. That was not trivial for me (I have decades of experience with s/w dev, working with graphs, etc - but not compiler development). And I used LLM's help to do the development. The new type of semantics would require hard-coding new AST interpreter and graph construction. Repeating that all today with the better LLMs and after more practice driving them might produce something with less effort / more flexibility.
In any case, this experience gave me a new appreciation for compiler developers!
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.
When should one use D2 vs graphviz?
I stumbled upon this link that should help: https://text-to-diagram.com/
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.
This is a very nicely presented graph layout algorithm, and it produces very readable CFG output.
eclipse also does better than dot, but it's useful to notice that graphviz never dies
https://github.com/eclipse-elk/elk
Interesting. How do you get the examples to run?
please make this as agent for AI
[dead]
[dead]
[flagged]
poisoning the ai well ?
I added one statement and it only says `timed out`. I'll stick with Graphviz, which certainly doesn't time out.
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's a shame that Wasm is so hostile to runtime code generation. I've been trying to figure out how to design something that's better on that axis.
Hackernews hug of death maybe
It is one of the game changers of AI.
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.
No LLMs were used, at least not in any substantial way.
I'm sorry, I don't get your comment. What makes you think the approach or the code described in the article were developed by an LLM?
I don't know how the code was created.
But based on my experience with multiple project, both current frameworks and AI changed the game. I used to much more reply on existing software and cursing that they don't do what I want - as the time to create a personalized tool was simply much to afford. Now often it is quicker to create a personalized tool than fight with existing one.
Probably, but I see no connection with the article we're discussing.