[HN Gopher] Who needs Graphviz when you can build it yourself?
___________________________________________________________________
Who needs Graphviz when you can build it yourself?
Author : pdubroy
Score : 426 points
Date : 2025-10-29 05:17 UTC (17 hours ago)
(HTM) web link (spidermonkey.dev)
(TXT) w3m dump (spidermonkey.dev)
| ctenb wrote:
| 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)
| lasfter wrote:
| 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.
| j2kun wrote:
| 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.
| kylereeve wrote:
| That's how all application-specific specializations work
| though, take advantage of domain properties that make you
| need a less generic algorithm.
| xlii wrote:
| 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.
| JohnKemeny wrote:
| Sounds intriguing. What is an example of a chart and its
| language that you have designed so far?
| xlii wrote:
| 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 :)
| nyrikki wrote:
| 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.
| JohnKemeny wrote:
| I added one statement and it only says `timed out`. I'll stick
| with Graphviz, which certainly doesn't time out.
| rag-hav wrote:
| Hackernews hug of death maybe
| bvisness wrote:
| 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.
| kragen wrote:
| 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.
| thw_9a83c wrote:
| 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.
| nirava wrote:
| 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 ...
| a_t48 wrote:
| 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.
| nirava wrote:
| 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...
| rapnie wrote:
| You might also check out D2, which had a recent run on the HN
| front page.
|
| https://news.ycombinator.com/item?id=45707539
| benterix wrote:
| 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.
| aqula wrote:
| 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...
| tauchunfall wrote:
| >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.
| kragen wrote:
| 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.
| eisbaw wrote:
| Wow, thank you very much. I like the graphviz dot language. I may
| translate this to Rust.
| IshKebab wrote:
| 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.
| zem wrote:
| 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.
| stefs wrote:
| 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.)
| whizzter wrote:
| 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).
| lexh wrote:
| 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/
| rs186 wrote:
| 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.
| benterix wrote:
| 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)."
| rs186 wrote:
| 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.
| hawk_ wrote:
| > if a Contributor Distributes
|
| Doesn't this only apply to contributors and dev users?
| kragen wrote:
| I think it applies to anyone who distributes it;
| https://www.eclipse.org/legal/epl-2.0/ says:
| "Contributor" means any person or entity that Distributes
| the Program.
| benterix wrote:
| 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.
| kragen wrote:
| 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.
| 1gn15 wrote:
| Can't you buy an exception to the license?
| rs186 wrote:
| Not my call.
| zvr wrote:
| 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.
| fulafel wrote:
| 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/
| embedding-shape wrote:
| 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.
| zvr wrote:
| > 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.
| stronglikedan wrote:
| At least Imagemagick came to their senses and renamed their
| command to magick (with convert still aliased for BC).
| wswope wrote:
| 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.
| Someone wrote:
| > 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.
| wswope wrote:
| 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.
| a_e_k wrote:
| You can also set: layout = neato;
|
| 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.
| rurban wrote:
| 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
| Ghoelian wrote:
| Why would you need Claude for that?
| rurban wrote:
| Kimi is also good. New habits, you know
| bvisness wrote:
| 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?
| bvisness wrote:
| 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.
| bvisness wrote:
| 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.)
| stared wrote:
| 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".
| benterix wrote:
| 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?
| stared wrote:
| 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.
| benterix wrote:
| Probably, but I see no connection with the article we're
| discussing.
| jrrrp wrote:
| 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.
| bvisness wrote:
| No LLMs were used, at least not in any substantial way.
| frumiousirc wrote:
| 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.
| HarHarVeryFunny wrote:
| 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).
| housel wrote:
| "clang -Xclang -ast-dump=json" will take you partway there.
| le-mark wrote:
| 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?
| bvisness wrote:
| 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.
| taeric wrote:
| I confess I found the graphs GraphViz made for me in
| https://taeric.github.io/many_sums.html oddly pretty. :D
| jerf wrote:
| "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...
| jesuslop wrote:
| Enterprise architect ($$) had that buried in the gui, and
| wondered for long if obsidian canvas could do the same,
| reports wanted.
| kiitos wrote:
| > 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...
| jesuslop wrote:
| Yep, agreed. CMake does deps graphviz (been there), that is
| better than nothing. But big diagrams need support for
| exploding subdiagrams and going back.
| dfabulich wrote:
| 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.
| taeric wrote:
| 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.
| aqula wrote:
| 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?
| pestaa wrote:
| 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...
| aqula wrote:
| Thanks for sharing. Although diagrams have a unique
| requirement that the boxes are inter-connected, and those
| connections must also look "nice".
| HarHarVeryFunny wrote:
| 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).
| phplovesong wrote:
| 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.
| hawk_ wrote:
| When should one use D2 vs graphviz?
| RationPhantoms wrote:
| I stumbled upon this link that should help: https://text-to-
| diagram.com/
| ynniv wrote:
| eclipse also does better than dot, but it's useful to notice that
| graphviz never dies
|
| https://github.com/eclipse-elk/elk
| realityfactchex wrote:
| 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.
| bvisness wrote:
| "I love the status quo! My favorite thing about it is that it
| is the status quo."
| dllu wrote:
| 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...
| anotheryou wrote:
| 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
| OisinMoran wrote:
| 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.
| bvisness wrote:
| 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.
| kragen wrote:
| This is a very nicely presented graph layout algorithm, and it
| produces very readable CFG output.
| Western0 wrote:
| please make this as agent for AI
| tunesmith wrote:
| 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.
| kiitos wrote:
| 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
___________________________________________________________________
(page generated 2025-10-29 23:01 UTC)