<povik>
how much interest would there be for an interactive viewer of rtlil?
<jix>
I think that would be quite useful
<jix>
while I know how to use the selection syntax to eventually get the information I want, I think being able to interactively expand input/output cones could be much faster
<jix>
especially when looking at a bit more logic at the same time, changing the selection can cause graphviz to relayout everything in a completely different way which I think could be avoided for something interactive (at least the kind of interactive viewer I'm thinking of, not sure if that matches what you have in mind)
mwk has quit [Ping timeout: 246 seconds]
<povik>
it does, and the incremental layout is exactly what i couldn't find an off-the-shelf solution for when i tried putting together a prototype of the thing few months ago
<povik>
so i had incremental expansion of the input and output cone, but had to rerun graphviz's layout at each step
mwk has joined #yosys
<povik>
which i realigned on the cell where the focus was, but once graphviz did something too different the mental context was lost
<jix>
I'v seen some d3.js stuff that uses interactive force directed layout of graphs (not in the context of netlists) with drag and drop for manually moving nodes which makes up quite a bit for force directed layout not being as good as other layout algorithms at untangling things
<povik>
initially i thought graphviz would support partially pre-constrained layout, but only once i start hacking xdot for the interactive viewer have i found out it does not... :)
<povik>
at least not with the layout engine we want to use for circuits, it does support it in general
<jix>
and force directed layout is much easier to implement and can be trivially intitialized with any given layout, so that's probably what I'd try first
<jix>
This is something https://map.ffmuc.net/#!/en/graph that uses it to visualize wifi mesh networks, updating in realtime when the connectivity changes.
<jix>
Another approach I have been thinking of is to store a planarization of the graph after layouting (i.e. turn any crossing wires into a special vertex that represents that crossing to make the graph planar) using a https://en.wikipedia.org/wiki/Combinatorial_map
<tpb>
Title: Combinatorial map - Wikipedia (at en.wikipedia.org)
<jix>
when you add new things, you use some heuristic that minimizes new crossings to insert it into the given map (i.e. without changing the topology of the previous layout) and then postprocess it with some hill climbing heuristic that only uses local changes to clean up the layout (and maybe also display them animated so you can visually track that)
<jix>
a combinatorial map is nice in that it allows you to represent the planar topology without worrying about any specific dimensions, so you can decouple the problem of getting a good planar toplogoy completely from the problem of computing positions and distances so things don't collide (although going from just the planar topologoy to a fully layouted graph is still not trivial)
<povik>
fancy :)
<povik>
sounds like a sane way to divide the problem
<jix>
last time I looked into graph layout (a few years ago by now I think) I didn't find any usable open source graph layout library based on that approach, IIRC there is quite a bit of academic work on planarization based layout algorithms though