everbeek
commented
9 years ago The linkStrength does not seem to have any effect.
I looked again at the collision detection example, in three browsers. In Chrome and IE, it runs rather quickly, but in Firefox, there is an open bug regarding SVG rendering, which hasn't quite been fixed yet. There are indications it will be fixed soon though. The example has more nodes than we generally would have, so if that example works swiftly, we could probably use that approach to deal with nodes overlapping due to arc pressure.
http://bl.ocks.org/mbostock/1748247
Ok, I just checked my FF verison, and went from 33.x to 34, and it has dramatically sped up SVG rendering! I feel like I have entered the future.
I should test this example with IE 9 as well though (25% of IE users; another 20% use IE8 which does not support SVG anyway; Chrome and FF users have a strong tendency to upgrade in a fairly timely fashion, so they would receive fine performance with collisions). Testing with IE11 emulation shows 8 to fail, and IE9 and also 10 to do fine, but do I trust that they are actually using SVG engines that would be used in the wild? I should use a Win7 VM to test this out, as it seems to be the only honest way to test it.
I have a virtual machine with IE10 running...that was acceptable. I need to get an image with IE9 on it though.
Tried IE9, and performance seems acceptable to me. I shall try setting up collision detection again.
Try these to see if they improve force layout behavior: -use locus in center to control overall force position -increase weights on inheritance, slightly on composition, lowest for mapping.
https://github.com/mbostock/d3/wiki/Force-Layout#linkStrength
The force.linkStrength parameter to the layout can be a function, which would be applied to each edge. This is how we would modulate the inheritance, composition, property relation and mapping arc strengths. Alternatively, the force.theta property is a global node repulsion parameter, and this could also get the desired effect. It is implemented in an efficient way, n*log(n), but we'd have to see how it ran.
I hope that linkStrength changes will cause nodes in the following export data to be laid out without throwing parallel series of inheritance and composition arcs together, and thus not putting lots of nodes into the same space. The export is produced from an Eye Part concept expansion on this base graph: http://127.0.0.1:8888/conceptPathToRoot.html?gwt.codesvr=127.0.0.1:9997&initial_vis=term_neighborhood&ontology_acronym=SNOMEDCT&full_concept_id=http%3A%2F%2Fpurl.bioontology.org%2Fontology%2FSNOMEDCT%2F81745001