Author of a web-based GraphViz editor [1] here. We're currently using viz.js [2], which is the original GraphViz compiled to WASM. Since viz.js is unmaintained, we're looking for a replacement.
This library looks really promising! As it's written in rust, it should be possible to port it to WASM. Are there plans in that direction?
Is it planned to be a drop-in replacement for GraphViz (or the dot engine)?
Does the standard implementation include any similar debug rendering? Seems like the coolest part of the project!
I tend to stay away from Graphviz a lot more than I otherwise would these days due to the lack of manual formatting controls (have spent waaaayyy too many hours writing code to add invisible edges between certain nodes to force row-ordered layouts).
Hah, that's hilarious. I also like graphs but hate manually laying them out, so I always use Graphviz and live with the results. Sometimes I think I could do better, but typing "foo -> bar" a few times is so much easier than spending any time thinking about what would look nicest. One time I added colors though, that was kind of nice.
It would probably be helpful to the community if we could add a layout plugin to allow users to specify layouts in some absolute or relative grid format, to avoid all the invisible edge and edge length hackery. We just need appropriate funding.
We have some amazing maintainers who work on gitlab.com/graphviz/graphviz now, but the think is, there are far more bug reporters than bug fixers. The first gen of Graphviz authors are timing out, so we very few people are around now to fix relatively deep semantic or logical bugs, c.f. https://xkcd.com/2347/
In case you come back to revisit ...
First I will note my comment appears nested one level deeper than I had been aiming for which may make it sound less positive than I intended. Second, Graphviz doesn't need to do anything to appease control freaks. You have been absolutely rocking it for decades. The important part of my glib description is 'competent' and to accept the very, very fair tradeoff between; already done with minimal effort and satisfying some fashion police insisting you do it their way when in reality they can't produce results themselves.
The bottom line is,
I can not thank you enough for releasing your software way back when I built it on my Amiga, you have been a constant companion in my career.
I wish it would output to graphml or something I could slightly edit with yEd or some manual tool. Does anybody have recipes for that? Or having generate some tikz simple layout and then moving on without dot? I can't say I have good memories of inkscape + dot svg output...
Pos doesn’t work with most layout engines (most notably dot), making it kinda useless, and graphviz doesn’t easily expose the dimensions of a node to accommodate dynamic layout. You can work around that, but that’s nowhere near as ergonomic as some sort of “tree level”-like argument that would force a node to position at a certain Y-coord while leaving the automatic layout process otherwise intact.
I've used it many times with neato and it works alright. Of course, there's always some "tweaking" to do if you want the end graph to look right, but this is always the case.
Nice! The general pattern I've encountered with graphviz is to start with it and hope you're done before it starts segfaulting on your data. Would be interesting to see if this helps.
One of the things I rarely see in other graphing tools is the concept of node clusters. Super helpful in a bunch of situations I've encountered and wish it was more broadly implemented in other layout engines.
> The general pattern I've encountered with graphviz is to start with it and hope you're done before it starts segfaulting on your data
I've generated diagrams from various sources of data in AWS (security groups, EC2 instances w/ their attached security groups, edges between, etc) and never run into this issue. I'm talking thousands to tens of thousands of nodes and tens of thousands of edges.
The utility of these diagrams was limited, given how dense they were. I'm curious what use case graphviz chokes on that would generate legible graphs..
edit: this reminds me that it would be useful for the AWS APIs to return a "modification epoch" number inside API responses, so that while you're enumerating/describing thousands upon thousands of resources, you could at least keep track of whether there have been any modifications between your first and your last Describe* call.
Add 3-4 zeroes. Gephi is good for larger graphs but most of my use cases involve a compartmentalization context that isn’t part of typical graph layout semantics (including gephi).
None of these tools are actually appropriate for the job, just never get the time to build something better.
How is performance compared to Graphviz?
There are some large compiler Control flow graphs with 500+ nodes where Graphviz really starts to take a long time to build a layout (dozens of seconds or worse). Profiling dot a bit, saw that most time was spent doing some DFS, and a lot of the data structs seem to be linked lists, the opposite of cache friendly.
> But man, endlessly fiddling to fix the layouts is time I'd like back in my life
I know many engineers are perfectionists, but pick your battles. It’s not as if the alternative of manually laying out every node and edge and maintaining it is universally better.
And your text-based diagram tools. Kroki[1] has merged block, sequence, Plant UML, packet, Mermaid, GraphViz, and numerous other textual diagram formats into a simple REST API. A while back I integrated the API into my text editor so that I could use variables inside of diagrams[2] (such as character names in a sci-fi story that are also presented in a GraphViz-based family tree).
Really glad to see this! Really want an easy way to render graphs in Rust without resorting to the graphiz binary.
What is the current status? Not seeing it listed anywhere, like if there are features that are not supported or if it uses certain layout algorithms but others are desired.
Would you be willing to make a `[lib]` available? I see you have a `lib.rs` but it'd be great if using it didn't require pulling in `[[bin]]` dependencies (you can mark them as optional and mark `required-features` on your bin like pulldown-cmark does [0] or split it into a separate crate in a workspace). It'd also be good to find an available name for the lib and get it published (looks like someone might be squatting on `layout`).
--> src/core/color.rs:180:21
|
180 | for pair in KNOWN_COLORS {
| ^^^^^^^^^^^^ borrow the array with `&` or call `.iter()` on it to iterate over it
|
= help: the trait `Iterator` is not implemented for `[(&str, u32); 148]`
...
error[E0277]: `[geometry::Point; 20]` is not an iterator
--> src/topo/placer/edge_fixer.rs:272:39
|
272 | for offset in offsets {
| ^^^^^^^ borrow the array with `&` or call `.iter()` on it to iterate over it
Rust 1.53 is from June 2021 and that's where this first works (until Rust Edition 2021 you can't actually just method call into_iter() on arrays because that would mask syntax that could work in some cases on older Rust code, but this code uses the for loop which does not actually do a method call to get the iterator)
This (arrays implementing IntoIterator) is probably the improvement with broadest impact of the last 12 months.
It even makes lots of Rust's documentation examples more readable. Previously if there's an iterator involved somewhere, the doc example ends up constructing say vec![1,2,3,4,5] and a reasonable novice might ask why do we use a vector here? Today Rust's documentation just says [1,2,3,4,5] because sure, an array of five elements 1, 2, 3, 4, 5 that makes sense why use any other data structure?
Been studying research papers on graph visualization.
It looks like we need some Deep Learning / ML based approach to this.
There is just so much meaning is encoded into XY coordinates and edges. Basic algorithms like Sugiyama produce meaningful visualizations only for simple and basic graphs.
When number of edges goes to the roof or nodes.. basic algorithms break down. Graphs become meaningless.
You have to make graphs by hand to make sense of it.
ML approaches to graph layout are very exciting, since the constraints people need in real life diagrams are quite intricate, but it's still a research problem.
yes. I would scale, zoom, adjust opacity, etc. Grouping into large/smaller clusters. Typically manual work is to do groups, their shapes, connections, how to highlight important info with colors or symbols and general meaning of X and Y axis. Very similar to drawing on a whiteboard. Whatever code I run, it is often very customized to make something exactly what I want.
ML would def benefits here to capture all these heuristics.
I'd recommend checking out the API Guidelines for some thoughts on this. The default recommendation if you don't have another preference is MIT + Apache 2.0
Awesome! I've always wanted a library that would be do interactive graph rendering -- I'd love to see this hooked up with egui such that you can detect clicks on nodes and highlight them or edit them.
In theory you could rasterize and center the result in the box. In practice, good luck accounting for how ascenders and descenders alter the visual balance to make something that feels "right". I've spent way too much time fiddling with borders on my photos, I don't want to imagine working with something so unruly as text!
Nah, it’s not new. Even remarking that the hot thing is reimplementing things in Rust is not new, you find at least one similar remark on almost every candidate thread. Remarking about such remarks is somewhat less common. :-)
This library looks really promising! As it's written in rust, it should be possible to port it to WASM. Are there plans in that direction?
Is it planned to be a drop-in replacement for GraphViz (or the dot engine)?
[1]: https://edotor.net [2]: https://github.com/mdaines/viz.js