Open FalseProtagonist opened 2 years ago
The distance calculation is particularly problematic when adding labels to edges:
Ideally the distance should be from node border to node border.
Perhaps this can be approximated by scaling the X distance to be larger than the Y distance; instead of using sqrt(x^2+y^2)
something like sqrt((2x)^2+y^2)
?
Can anyone point to where the calculation is done in the source code so that I can experiment with it?
@tgdwyer Please consider allowing users to override the distance calculation. The Pull Request moves the calculation of dimension distance into a static function so that users can modify the behavior. This allows users to provide their own distance calculation, for example:
Descent.dimensionDistance = (x, i, u, v) => {
var dx = x[i][u] - x[i][v];
var dedge = i==0 ? (this._nodes[u].width + this._nodes[v].width)/2
: (this._nodes[u].height + this._nodes[v].height)/2;
if (dx > dedge) {
dx -= dedge;
} else if (dx < -dedge) {
dx += dedge;
} else if (dx != 0) {
dx /= 10;
}
return dx;
}
Is there a suggested approach to optimize for a link length relative to the edges of the box of a node instead of the midpoint of the box?
So that the "outside-part" of the links in the below diagram would appear equal and not very different:
One approach that I thought of would be to try and have a highly dynamic linkLength fn which traverses the mutable tree (it's passed the link, which I think will have runtime pointers to the nodes?), and then offsets the linkLength dependant upon the current relative positions of the nodes (by subtracting the section of box that it's currently being drawn over, basically). Even if that's possible which I'm not sure of, it seems that it would likely break some assumptions of the algorithm because of the amount the ideal link length is changing as the line goes from vertical to horizontal.