Sample graph in SVG:
This is executing clientside (for better or worse; yours is much faster :) )
I created http://agile.pics a couple years ago based on the .js graphviz library.
The site is a thin wrapper that renders Graphviz of Sequence Diagrams from GitHub gists.
agree completely; GraphViz is extraordinary.
for intance, Yifan hu (U Florida faculty, i think) maintains a spectacular gallery of very large graphs comprised of millions of nodes, all rendered using GraphViz (persisted and input to GraphViz as incidence matrices):
The graphs in the gallery i liked to above were rendered using sfdp, one of the 5-6 layout engines in GraphViz, and which is the GraphViz engine of choice for very large undirected graphs not limited to a particular layout geometry
I guess the reason that commercial solutions rarely get discussed in such contexts is that they are quite expensive if you're a single developer hacking away at a side project. Even our cheapest license is already five figures (considering Tom Sawyer also rather target enterprise customers they won't be cheaper) and to be honest, I'd think hard about paying that if I'm not absolutely sure I'd get the money back somehow. For larger companies it's less of an issue, of course, or the cost just gets billed to their customer as part of the project cost.
But probably the answer will be that few customers asked so far and/or it might be fairly easy to accomplish with customizing one of the existing layout algorithms. We did something similar with our example BPMN implementation where a pre-processing step applied constraints for the hierarchic layout based on the node/edge types in the diagram. The vast majority of things customers ask of us are actually fairly easy to implement without necessarily having them in the library. So we have very few layout algorithms that are applicable to exactly one kind of diagram (family trees are an exception, but even that is just a wrapper around a more general-purpose algorithm).
The advantage is that there are very many knobs and configuration options to fiddle with to get the layout you want. The disadvantage is that there are very many knobs and configuration options to fiddle with, where having special layouts for certain types of graphs might be easier but not as flexible.
In the end, it's a library and the users (from our perspective) are developers and those shouldn't shy away from writing some code. It would be nice to also appeal to people who just want some data laid out nicely. To some extent that works already², but such wishes have to be balanced with what people are willing to pay for :-)
¹ Happens often with very domain-specific graphs; last thing mentioned I didn't know was some kind of diagram to describe pipes, valves, and water flows in buildings.
² e.g. http://live.yworks.com/yfiles-for-html/2.0/databinding/graph... has only very minimal user code
 https://hackerone.com/reports/88395, https://secure.phabricator.com/T9408
But to be honest, a container approach would probably be better today.
P.S. if you're interested, just the other day I posted a related experiment of mine on Show HN ... https://news.ycombinator.com/item?id=13308150
This is not discussed much in all the talk about social networks. It's always the graph (the "one") that's foregrounded, rather than the multiplicity of edges, each a relation.
I know this is mathematically an obvious thing, but surely the relational perspective is more amenable to generalization. We should make more of it.
Which makes weighted graphs perfect for representation by matrices!
Studying adjacency matrix of weighted, directed graphs gave me a profound realization matrices are a table of relationships between their "dimensions". I never looked at matrices the same way again. I realized that the identity column was literally the entries that represented a relationship between a dimension/node and itself. I went down many rabbit holes... particularly the question of graph isomorphism. That problem is a rabbit hole. Another rabbit hole is the Hamiltonian cycle problem.
P.S. check out hypergraphs, which are not necessarily binary relations and generalize graphs. Incidentally, hypergraphs have an adjacency tensor. I've started to understand that tensors are like 'tables' of relationships between dimensions + dimensions representing some or all of their possible combinations.
By the way, if you can figure out a way to do fast multiplication of matrices over degree-truncated polynomial rings, I'll show you a fast way to count the number of hamiltonian cycles in a graph. These problems are intricately linked.
That Wikipedia adjacency matrix would be interesting to visualize, though. There are tools out there for visualizing sparse matrices as graphs:
About the external shape loader issue - this code is somewhat centralized in graphviz/lib/gvc/gvusershape.c and in gvrender.c which calls it, and I thought it could be disabled at compile time (because we did address the security concerns at one point) and there's a lot of other machinery to control compile time features. Maybe John Ellson can comment here. Kudos to John for recognizing the problems with the shape loader as soon as I proposed it but apparently that didn't stop us at the time.
I'd like to see more work like the paper from a few years ago which ran PageRank and HITS on Wikipedia to discover the most central pages. The PageRank result indicated church hierarchy and nation states were important, while HITS had things like "television" "animal" as the most authoritative/central pages.
There is so much structure there to be investigated.
The point was that, for a simple directed graph, the edges represent a binary relationship. While for a weighted directed graph, it represents a relationship-matrix. For the graph being non-directed this would mean, that the relationship(-matrix) is symmetric.
Meaning that any algebra, algorithm, proof, etc. on graphs of that type can be applied for the other interpretation as well.
Implementation is a different question. "Most" binary relations we happen upon (less-than as the obvious) have an infinite domain and infinite cardinality (when represented as a set of tuples), making it very hard to "visualize" as a graph.
If you can't represent some well in a graph because it's too messy, you could try using an adjacency matrix, along with a clustering algorithm to figure out how to order the columns / rows.
I needed to use something to render directed graph in the browser and the biggest problem was the download size.
This library is 851KB gzip, which is way better than the 1.3MB I was using.
Maybe being able to bundle the engines (and output format) as separate modules could reduce its size?
So once again, great work!
e.g. live online editor:
It also scales for large graphs
It's wonderful and I love being able to use my $EDITOR / awk / sed / etc to manipulate the results.
Its really just a hack where graphviz uses inotify() to watch for changes in a file being edited by vim.
I'd like to render complex graphs with Mapnik, as I do for OSM (which is just a graph after all).
I'd be very grateful for suggestions.
A good intro is at: https://romanegloo.wordpress.com/2012/03/29/generating-a-cal...
I like the robot one, but I don't believe that these in any way contribute to the post.