Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Dot] Spinning (also forum does not seem to be accepting questions.) #1172

Closed
ianamason opened this issue Nov 19, 2016 · 49 comments
Closed

[Dot] Spinning (also forum does not seem to be accepting questions.) #1172

ianamason opened this issue Nov 19, 2016 · 49 comments

Comments

@ianamason
Copy link

So I tried posting this on the graphviz.org forum but to no avail.
The connection always timed out. So I will repost it here.

We have a graph (yes I know it is large) that is not too much bigger
than other graphs we render relatively painlessly. I have tried limiting
all the things I can find to limit but alas dot appears to spin.

DotIssues iam$  dot -v -Ln3 dotIn.xdot -Txdot -o dotOut.xdot
dot - graphviz version 2.39.20141015.0446 (20141015.0446)
libdir = "/usr/local/lib/graphviz"
Activated plugin library: libgvplugin_core.6.dylib
Using render: xdot:core
Using device: xdot:xdot:core
Activated plugin library: libgvplugin_dot_layout.6.dylib
Using layout: dot:dot_layout
The plugin configuration file:
	/usr/local/lib/graphviz/config6
		was successfully loaded.
    render	:  dot fig map pic pov ps quartz svg tk vml xdot
    layout	:  circo dot fdp neato nop nop1 nop2 osage patchwork sfdp twopi
    textlayout	:  textlayout
    device	:  bmp canon cgimage cmap cmapx cmapx_np dot eps exr fig gif gv icns ico imap imap_np ismap jp2 jpe jpeg jpg pct pdf pic pict plain plain-ext png pov ps ps2 psd sgi svg svgz tga tif tiff tk vml vmlz xdot xdot1.2 xdot1.4
    loadimage	:  (lib) bmp eps gif jpe jpeg jpg pdf png ps svg
pack info:
  mode   undefined
  size   0
  flags  0
  margin 8
pack info:
  mode   node
  size   0
  flags  0
fontname: unable to resolve "Times-Roman"
network simplex:  1289 nodes 8029 edges maxiter=2147483647 balance=1
network simplex: 100 200 300 400
network simplex: 1289 nodes 8029 edges 419 iter 0.03 sec
Maxrank = 73, minrank = 0
mincross: pass 0 iter 0 trying 0 cur_cross 7322238 best_cross 7322238
mincross: pass 0 iter 1 trying 0 cur_cross 6052740 best_cross 6052740
mincross: pass 1 iter 0 trying 0 cur_cross 5245322 best_cross 4648732
mincross: pass 1 iter 1 trying 1 cur_cross 5721246 best_cross 4648732
mincross: pass 2 iter 0 trying 0 cur_cross 4648732 best_cross 4648732
mincross: pass 2 iter 1 trying 1 cur_cross 5818126 best_cross 4648732
mincross temp: 4648732 crossings, 98.92 secs.
network simplex:  213718 nodes 323873 edges maxiter=3867 balance=2

It sits at this last line for as long as I have the patience to wait
(currently a couple of hours). We are not that fussy about the layout,
but we are addicted to xdot output, because we use it to draw our graphs
in an interactive java environment, in particular the nodes and edges.

Any suggestions? (other than me checking out the GitHub repo and seeing
what has got its knickers in a knot). I put the graph in question here:

http://www.csl.sri.com/users/iam/dotIn.xdot

@magneticnorth
Copy link
Collaborator

network simplex: 213718 nodes 323873 edges maxiter=3867 balance=2
It sits at this last line for as long as I have the patience to wait
(currently a couple of hours). We are not that fussy about the layout,
but we are addicted to xdot output, because we use it to draw our graphs
in an interactive java environment, in particular the nodes and edges.

Any suggestions? (other than me checking out the GitHub repo and seeing
what has got its knickers in a knot). I put the graph in question here:

http://www.csl.sri.com/users/iam/dotIn.xdot http://www.csl.sri.com/users/iam/dotIn.xdot
spline routing problem?

wonder if this is related to recent work on eliminating compile time
warnings about floating point conversions? try an older version?

@ianamason
Copy link
Author

ianamason commented Nov 19, 2016

OK so I spoke to soon. It eventually finished.

...
network simplex:  213718 nodes 323873 edges maxiter=3867 balance=2
network simplex: 100 200 300 400 500 600 700 800 900 1000
network simplex: 1100 1200 1300 1400 1500 1600 1700 1800 1900 2000
network simplex: 2100 2200 2300 2400 2500 2600 2700 2800 2900 3000
network simplex: 3100 3200 3300 3400 3500 3600 3700 3800
network simplex: 213718 nodes 323873 edges 3867 iter 11918.03 sec
routesplines: 10729 edges, 218765 boxes 23.70 sec
Using render: xdot:core
Using device: xdot:xdot:core
gvRenderJobs temp: 0.82 secs.

But I would really like to be able to speed it up a bit.... 3.3 hours is
a tad slow UI wise.

The three hour run is the uncommented version. I have yet to succeed
with the one commented out (but didn't let it run that long).

/* graph [xdotversion=1.2, rankdir=TB, nslimit=3, nslimit1=3, maxiter=3, mclimit=0.1, searchsize=5]; */
graph [xdotversion=1.2, rankdir=TB, nslimit=3, mclimit=0.1];

@magneticnorth
Copy link
Collaborator

Yes, it seems to be hung in the network simplex solver for the X coordinate phase.

This is a bit unusual. It has nothing to do with floating point arithmetic.

We sometimes wondered if it was possible for the network simplex solver to get
stuck in a phase where it would swap a lot of tight tree edges without making any
progress, but never found an example. (Until now?)

On Nov 18, 2016, at 8:18 PM, Ian A Mason notifications@github.com wrote:

OK so I spoke to soon. It eventually finished.

...
network simplex: 213718 nodes 323873 edges maxiter=3867 balance=2
network simplex: 100 200 300 400 500 600 700 800 900 1000
network simplex: 1100 1200 1300 1400 1500 1600 1700 1800 1900 2000
network simplex: 2100 2200 2300 2400 2500 2600 2700 2800 2900 3000
network simplex: 3100 3200 3300 3400 3500 3600 3700 3800
network simplex: 213718 nodes 323873 edges 3867 iter 11918.03 sec
routesplines: 10729 edges, 218765 boxes 23.70 sec
Using render: xdot:core
Using device: xdot:xdot:core
gvRenderJobs temp: 0.82 secs.
But I would really like to be able to speed it up a bit.... 3.3 hours in
a tad slow UI wise.

The three hour run is the uncommented version. I have yet to succeed
with the one commented out (but didn't let it run that long).

/* graph [xdotversion=1.2, rankdir=TB, nslimit=3, nslimit1=3, maxiter=3, mclimit=0.1, searchsize=5]; */
graph [xdotversion=1.2, rankdir=TB, nslimit=3, mclimit=0.1];

You are receiving this because you commented.
Reply to this email directly, view it on GitHub #1172 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ACtWz3zFNM5CSiU6_a22oCPUvB1bggPyks5q_mqigaJpZM4K3IQg.

@ianamason
Copy link
Author

ianamason commented Nov 20, 2016

The graphs are generated by inductively closing a set of biological reaction rules.
So the rule nodes have an obvious rank, and by adding those ranks I have managed
to reduce the time it spends in the stage between where it prints:

network simplex:  97406 nodes 149452 edges maxiter=1289 balance=2

and when it starts to print

network simplex: 100 200 300 400 500 600 700 800 900 1000
network simplex: 1100 1200
network simplex: 97406 nodes 149452 edges 1289 iter 2390.80 sec

to just over half an hour. This is still too long from the point of view of
our tool being usable. I have tried dialing back all the knobs I can find:

dot -v rdotIn.xdot -Txdot -o rdotOut.xdot

with the graph annotations being:

graph [xdotversion=1.2, rankdir=TB, nslimit=1, nslimit1=1, maxiter=1, mclimit=0.1];

So unless you have something to suggest we are at wits end here.

Any suggestions, such as what additional structure we could add that would
speed up the bottleneck, or knobs to dial, would be much appreciated.

@graphviz
Copy link
Collaborator

Maybe I can look at it next week.

It seems like an algorithm bug :-(

Sent from my iPad

On Nov 20, 2016, at 5:49 PM, Ian A Mason notifications@github.com wrote:

The graphs are generated by inductively closing a set of biological reaction rules.
So the rule nodes have an obvious rank, and by adding those ranks I have managed
to reduce the time it spends in the stage between where it prints:

network simplex: 97406 nodes 149452 edges maxiter=1289 balance=2
and when it starts to print

network simplex: 100 200 300 400 500 600 700 800 900 1000
network simplex: 1100 1200
network simplex: 97406 nodes 149452 edges 1289 iter 2390.80 sec
to just over half an hour. This is still too long from the point of view of
our tool being usable. I have tried dialing back all the knobs I can find:

dot -v rdotIn.xdot -Txdot -o rdotOut.xdot
with the graph annotations being:

graph [xdotversion=1.2, rankdir=TB, nslimit=1, nslimit1=1, maxiter=1, mclimit=0.1];
So unless you have something to suggest we are at wits end here.

Any suggestions would be much appreciated.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@ianamason
Copy link
Author

That would be great! Let me know if you need any thing. I put the ranked graph here:

http://www.csl.sri.com/users/iam/rdotIn.xdot

@ianamason
Copy link
Author

I'm hoping this hasn't fallen through the cracks....

@magneticnorth
Copy link
Collaborator

magneticnorth commented Dec 1, 2016 via email

@ianamason
Copy link
Author

Yes. Soon all science in the states will be funded by the NKF.

@magneticnorth
Copy link
Collaborator

magneticnorth commented Dec 1, 2016 via email

@ianamason
Copy link
Author

National Kickstarter Foundation.

@magneticnorth
Copy link
Collaborator

magneticnorth commented Dec 1, 2016 via email

@emdenrg
Copy link
Collaborator

emdenrg commented Dec 1, 2016 via email

@magneticnorth
Copy link
Collaborator

magneticnorth commented Dec 3, 2016 via email

@ianamason
Copy link
Author

I could learn how to do this, if there are no other takers. gprof?

@magneticnorth
Copy link
Collaborator

magneticnorth commented Dec 3, 2016 via email

@magneticnorth
Copy link
Collaborator

magneticnorth commented Dec 4, 2016 via email

@ianamason
Copy link
Author

Yes that does not look like a happy route. I'll do it on Monday on linux if you have no further luck being brave on a mac.

@ellson
Copy link
Owner

ellson commented Dec 4, 2016 via email

@ellson
Copy link
Owner

ellson commented Dec 4, 2016 via email

@ianamason
Copy link
Author

ianamason commented Dec 4, 2016

John,

Thanks for the effort, and the crystal clear instructions.

Stephen,

I followed John's instructions and let it run to completion.
The top 100% are

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  Ks/call  Ks/call  name    
 30.26    641.25   641.25    26297     0.00     0.00  treesearch
 24.41   1158.59   517.34        2     0.26     1.03  feasible_tree
 21.97   1624.24   465.65    26297     0.00     0.00  tight_tree
 13.51   1910.66   286.41 2010816878     0.00     0.00  add_tree_edge
  6.85   2055.76   145.10 1917958723     0.00     0.00  incident
  0.72   2071.12    15.36 516005856     0.00     0.00  left2right
  0.44   2080.50     9.39 91821370     0.00     0.00  out_cross
  0.42   2089.48     8.98 91821080     0.00     0.00  in_cross
  0.26   2094.98     5.50 604904071     0.00     0.00  ccw
  0.23   2099.95     4.97     1339     0.00     0.00  dfs_range
  0.19   2103.89     3.94      104     0.00     0.00  reorder
  0.14   2106.84     2.95    22375     0.00     0.00  transpose_step
  0.06   2108.17     1.33     8815     0.00     0.00  limitBoxes
  0.06   2109.35     1.18 27077146     0.00     0.00  solve3
  0.05   2110.38     1.03 18354447     0.00     0.00  connecttris
  0.04   2111.20     0.82  3929721     0.00     0.00  isdiagonal
  0.04   2112.01     0.81     5577     0.00     0.00  enter_edge
  0.04   2112.82     0.81     1851     0.00     0.00  dfs_enter_outedge
  0.04   2113.62     0.81 117668088     0.00     0.00  exchange
  0.04   2114.39     0.77      230     0.00     0.00  rcross
  0.03   2114.97     0.58 27072261     0.00     0.00  splineintersectsline
  0.03   2115.51     0.54   405097     0.00     0.00  grealloc
  0.02   2116.01     0.50        2     0.00     0.00  init_rank
  0.02   2116.42     0.41 11126565     0.00     0.00  dttree
  0.02   2116.83     0.41 74285093     0.00     0.00  intersects
  0.02   2117.15     0.32     1280     0.00     0.00  rerank
  0.01   2117.36     0.21     3726     0.00     0.00  dfs_enter_inedge
  0.01   2117.52     0.16                             mincross_clust
  0.01   2117.67     0.15   212949     0.00     0.00  finddqsplit
  0.01   2117.78     0.11 31103786     0.00     0.00  points2coeff


the full output is here:

http://csl.sri.com/~iam/analysis.txt

Hope this helps.

Ian.

P.S. This is dot's output:

 $PREFIX/bin/dot_static -v rdotIn.xdot -Txdot -o rdotOut.xdot
dot_static - graphviz version 2.39.20161204.1538 (20161204.1538)
Using render: xdot:core
Using device: xdot:xdot:core
Using layout: dot:dot_layout
Demand loading of plugins is disabled.
    render	:  dot dot_json fig json json0 map mp pic pov ps svg tk vml xdot xdot_json
    layout	:  circo dot fdp neato nop nop1 nop2 osage patchwork sfdp twopi
    textlayout	:
    device	:  canon cmap cmapx cmapx_np dot dot_json eps fig gv imap imap_np ismap json json0 mp pic plain plain-ext pov ps ps2 svg svgz tk vml vmlz xdot xdot1.2 xdot1.4 xdot_json
    loadimage	:  (lib) eps gif jpe jpeg jpg png ps svg
pack info:
  mode   undefined
  size   0
  flags  0
  margin 8
pack info:
  mode   node
  size   0
  flags  0
fontname: "Times-Roman" resolved to: [internal times]
network simplex:  402 nodes 847 edges maxiter=1289 balance=1
network simplex: 402 nodes 847 edges 48 iter 0.00 sec
Maxrank = 26, minrank = 0
mincross: pass 0 iter 0 trying 0 cur_cross 5226015 best_cross 5226015
mincross: pass 0 iter 1 trying 0 cur_cross 5120414 best_cross 5120414
mincross: pass 1 iter 0 trying 0 cur_cross 4893817 best_cross 4893817
mincross: pass 1 iter 1 trying 1 cur_cross 5253852 best_cross 4893817
mincross: pass 2 iter 0 trying 0 cur_cross 4893817 best_cross 4893817
mincross: pass 2 iter 1 trying 1 cur_cross 5253852 best_cross 4893817
mincross temp: 4893817 crossings, 47.10 secs.
network simplex:  97406 nodes 149452 edges maxiter=1289 balance=2
network simplex: 100 200 300 400 500 600 700 800 900 1000
network simplex: 1100 1200
network simplex: 97406 nodes 149452 edges 1289 iter 2096.10 sec
routesplines: 8815 edges, 108845 boxes 21.00 sec
Using render: xdot:core
Using device: xdot:xdot:core
gvRenderJobs temp: 0.91 secs.

@magneticnorth
Copy link
Collaborator

magneticnorth commented Dec 5, 2016 via email

@ianamason
Copy link
Author

I have it valgrinding away (quietly so far). Probably, given the usual slow down, it will take all night.
I'll add the results here in the morning.

@magneticnorth
Copy link
Collaborator

magneticnorth commented Dec 5, 2016 via email

@ianamason
Copy link
Author

Nothing suspect...

valgrind $PREFIX/bin/dot_static -v rdotIn.xdot -Txdot -o rdotOut.xdot
==17208== Memcheck, a memory error detector
==17208== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==17208== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==17208== Command: /home/iam/bin/graphviz/bin/dot_static -v rdotIn.xdot -Txdot -o rdotOut.xdot
==17208==
dot_static - graphviz version 2.39.20161204.1538 (20161204.1538)
Using render: xdot:core
Using device: xdot:xdot:core
Using layout: dot:dot_layout
Demand loading of plugins is disabled.
    render	:  dot dot_json fig json json0 map mp pic pov ps svg tk vml xdot xdot_json
    layout	:  circo dot fdp neato nop nop1 nop2 osage patchwork sfdp twopi
    textlayout	:
    device	:  canon cmap cmapx cmapx_np dot dot_json eps fig gv imap imap_np ismap json json0 mp pic plain plain-ext pov ps ps2 svg svgz tk vml vmlz xdot xdot1.2 xdot1.4 xdot_json
    loadimage	:  (lib) eps gif jpe jpeg jpg png ps svg
pack info:
  mode   undefined
  size   0
  flags  0
  margin 8
pack info:
  mode   node
  size   0
  flags  0
fontname: "Times-Roman" resolved to: [internal times]
network simplex:  402 nodes 847 edges maxiter=1289 balance=1
network simplex: 402 nodes 847 edges 48 iter 0.07 sec
Maxrank = 26, minrank = 0
mincross: pass 0 iter 0 trying 0 cur_cross 5226015 best_cross 5226015
mincross: pass 0 iter 1 trying 0 cur_cross 5120414 best_cross 5120414
mincross: pass 1 iter 0 trying 0 cur_cross 4893817 best_cross 4893817
mincross: pass 1 iter 1 trying 1 cur_cross 5253852 best_cross 4893817
mincross: pass 2 iter 0 trying 0 cur_cross 4893817 best_cross 4893817
mincross: pass 2 iter 1 trying 1 cur_cross 5253852 best_cross 4893817
mincross temp: 4893817 crossings, 826.90 secs.
network simplex:  97406 nodes 149452 edges maxiter=1289 balance=2
network simplex: 100 200 300 400 500 600 700 800 900 1000
network simplex: 1100 1200
network simplex: 97406 nodes 149452 edges 1289 iter 10676.54 sec
routesplines: 8815 edges, 108845 boxes 757.52 sec
Using render: xdot:core
Using device: xdot:xdot:core
gvRenderJobs temp: 37.47 secs.
==17208==
==17208== Process terminating with default action of signal 27 (SIGPROF)
==17208==    at 0x58754BE: __open_nocancel (syscall-template.S:81)
==17208==    by 0x5885F50: write_gmon (gmon.c:360)
==17208==    by 0x5886659: _mcleanup (gmon.c:428)
==17208==    by 0x57C61A8: __run_exit_handlers (exit.c:82)
==17208==    by 0x57C61F4: exit (exit.c:104)
==17208==    by 0x57ABF4B: (below main) (libc-start.c:321)
==17208==
==17208== HEAP SUMMARY:
==17208==     in use at exit: 68,504,964 bytes in 393,384 blocks
==17208==   total heap usage: 1,721,761 allocs, 1,328,377 frees, 221,936,115 bytes allocated
==17208==
==17208== LEAK SUMMARY:
==17208==    definitely lost: 12,840 bytes in 274 blocks
==17208==    indirectly lost: 19,440 bytes in 81 blocks
==17208==      possibly lost: 90,616 bytes in 1,255 blocks
==17208==    still reachable: 68,382,068 bytes in 391,774 blocks
==17208==         suppressed: 0 bytes in 0 blocks
==17208== Rerun with --leak-check=full to see details of leaked memory
==17208==
==17208== For counts of detected and suppressed errors, rerun with: -v
==17208== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Profiling timer expired

@magneticnorth
Copy link
Collaborator

magneticnorth commented Dec 6, 2016 via email

@magneticnorth
Copy link
Collaborator

magneticnorth commented Dec 6, 2016 via email

@ellson
Copy link
Owner

ellson commented Dec 7, 2016 via email

@ianamason
Copy link
Author

ianamason commented Dec 7, 2016

So my next avenue will be to try and trim the number of edges in the graph.
Since it appears that we are not going to have a quick fix.
Is this a possible route?

@magneticnorth
Copy link
Collaborator

magneticnorth commented Dec 7, 2016 via email

@graphviz
Copy link
Collaborator

graphviz commented Dec 9, 2016 via email

@magneticnorth
Copy link
Collaborator

magneticnorth commented Dec 9, 2016 via email

@magneticnorth
Copy link
Collaborator

magneticnorth commented Dec 9, 2016 via email

@graphviz
Copy link
Collaborator

graphviz commented Dec 9, 2016 via email

@magneticnorth
Copy link
Collaborator

magneticnorth commented Dec 11, 2016 via email

@ianamason
Copy link
Author

That is excellent news Stephen! We look forward to stress testing it for you...

@graphviz
Copy link
Collaborator

graphviz commented Dec 12, 2016 via email

@magneticnorth
Copy link
Collaborator

magneticnorth commented Dec 13, 2016 via email

@magneticnorth
Copy link
Collaborator

magneticnorth commented Dec 18, 2016

Snow day today, so I coded the new tight subtree merge, and it works well.
$ time dot_static dotIn.xdot -o /dev/null

real 4m18.03s
user 4m8.14s
sys 0m2.25s
$

I don't know if the layout is usable, but the solver seems OK. Here's a TODO list: It needs more testing. It leaks memory from ns.c lines 298, 406, 490 - I think the subtree descriptors can only be freed at the end of feasible_tree() because they can be referenced even after subtrees are merged. We should check the new alg. with valgrind. All the new(?) compilation warnings with clang LLVM 8.0 are annoying. A few debug printfs are commented out but maybe should be put back in and depend on the runtime debug level. I probably broke the formatting because I'm confused about what we're doing with tabs and spaces these days. That's what I have right now. I'm not checking this code in yet because of the above problems. When I have time I'll figure out how to use GitHub more reasonably. Hope this is useful.

ns.c.txt

@ianamason
Copy link
Author

That is great news Stephen. I have to do penance and go home for a summery xmas tomorrow, but I
will be back in the first few days of new year to try this out.

@magneticnorth
Copy link
Collaborator

Issue was fixed by rewrite of tight_tree() in lib/common.ns.c, took a few iterations to get it right,

@ianamason
Copy link
Author

Stephen,

So I have been testing it, and it has been handling the stress. I'm about to
hand it off to the biologists, so if they can't break it we can take the rest of
the decade off.

Thanks again for all your effort.

Cheers, Ian.

@ianamason
Copy link
Author

@magneticnorth asked:

Hi Ian. Can the biologists that use this software actually see anything meaningful in such large graphs?

but I do not see the question here, so here is the answer anyway. Just another GitHub oddity.

Stephen, That's the $64,000 question. I have tweaked the tool so they can
do a lot of stuff without displaying the graph, but they have a button that
will display it if they cannot help themselves. From looking at the graphs myself,
I think we need to reduce the edges (perhaps by not showing "enzymes" to the
rules), the number of nodes seems fine. In my hacking I goofed and was drawing the
graphs without rendering the edges for a time, and that actually seemed like a
good thing, so we shall see. I did have to optimize the java painting too.

@emden
Copy link
Collaborator

emden commented Jan 18, 2017

Did the test graph change? The initial run reported 73 ranks, but later on, I see reports of 26 ranks. And I am still getting 73.

Concerning how to get a better visualization, there are 3 tricks that immediately come to mind: transitive reduction, unflattening, and making edges semi-transparent. I have used the Graphviz tred tool to great effect frequently, but the current implementation limits its use for larger graphs. It would be worthwhile seeing if this code could be rewritten. In theory, it should be O(EV).

One can use the unflatten tool, but it would also be worth the effort to turn on the aspect ratio code again. It doesn't work with clusters or disconnected graphs, but a lot of input doesn't have clusters, and one can get around the disconnected problem by using the pack attribute with dot.

@ianamason
Copy link
Author

ianamason commented Jan 18, 2017

Yes there are two graphs in the fray: dotIn.xdot and rdotIn.xdot.
The latter was when we added the inductive rank of the rules nodes into
the generated dot, in an attempt to speed things up. I think we will first try
eliminating the edges that are less semantically important and see where that gets us.
semi-transparent edges sound interesting too, but my guess is they will still slow down the
java rendering anyway, which is also a bit of a drag currently.

@magneticnorth
Copy link
Collaborator

magneticnorth commented Jan 18, 2017 via email

@emden
Copy link
Collaborator

emden commented Jan 18, 2017

Thanks. I was misled that the number of edges and nodes was the same.

Removing less important edges is a big win. As for semi-transparency, try it before tossing it out. This appears to be well supported in current graphics systems.

@emden
Copy link
Collaborator

emden commented Jan 18, 2017

(I wish comments were numbered so you could specify which comment you were responding to.)

Following up on Stephen's comment two above, I'd like to recommend we use the issues for all communication about issues (unless we plan to resurrect the mailing list) and avoid private emails unless the comment really has limited relevance.

@magneticnorth
Copy link
Collaborator

magneticnorth commented Jan 18, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants
@graphviz @ellson @emden @magneticnorth @ianamason @emdenrg and others