You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently all edges are drawn and then all nodes are drawn in sigma.js. I believe this is because of the ordering of the WebGL contexts here: https://github.com/jacomyal/sigma.js/blob/main/src/sigma.ts#L222. The impact of this is that it is not possible for a user to show edges on top of a node. This is regardless of the zIndex set. But we often want to do just this. For example, the example on the sigma.js website (https://www.sigmajs.org/). If I hover over a node, the edges for that node necessarily are rendered under the greyed out nodes. It would be much easier to read / understand the network if these edges could be shown above the greyed out nodes.
Describe the solution you'd like
In an ideal world, the zIndex for nodes and edges would be respected across all nodes and edges together rather than nodes in isolation and edges in isolation. However, I can't see an elegant way of achieving this with the current codebase (perhaps someone else can?). In the alternative, I think it would be good to add a new WebGL context here: https://github.com/jacomyal/sigma.js/blob/main/src/sigma.ts#L222. Call it say edgesAboveNodes. Then, where we compute the zIndex extents (see here for example: https://github.com/jacomyal/sigma.js/blob/main/src/sigma.ts#L747) we would add a bit of extra logic to use those zIndexes to find if we have edges that should appear above any nodes and, if we do, isolate those edges and then render them after the nodes.
It's not a perfect solution as it doesn't provide full zIndex flexibility but it would at least give us the ability to have some edges over nodes. If zIndex is not set for edges or if the zIndex of all edges is less than or equal to the zIndex of all nodes than it would have no impact.
@Yomguithereal and @jacomyal - if I can write a proof of concept for the above would you be open to a pull request for it?
The text was updated successfully, but these errors were encountered:
On second thought, I actually think concatenating nodes and edges for the purpose of sorting by zIndex and then iterating through that concatenated, sorted array when drawing (and calling the appropriate program depending on whether it's a node or edge) should work and is likely a better solution.
Feature request template
Is your feature request related to a problem? Please describe.
Currently all edges are drawn and then all nodes are drawn in sigma.js. I believe this is because of the ordering of the WebGL contexts here: https://github.com/jacomyal/sigma.js/blob/main/src/sigma.ts#L222. The impact of this is that it is not possible for a user to show edges on top of a node. This is regardless of the zIndex set. But we often want to do just this. For example, the example on the sigma.js website (https://www.sigmajs.org/). If I hover over a node, the edges for that node necessarily are rendered under the greyed out nodes. It would be much easier to read / understand the network if these edges could be shown above the greyed out nodes.
Describe the solution you'd like
In an ideal world, the zIndex for nodes and edges would be respected across all nodes and edges together rather than nodes in isolation and edges in isolation. However, I can't see an elegant way of achieving this with the current codebase (perhaps someone else can?). In the alternative, I think it would be good to add a new WebGL context here: https://github.com/jacomyal/sigma.js/blob/main/src/sigma.ts#L222. Call it say edgesAboveNodes. Then, where we compute the zIndex extents (see here for example: https://github.com/jacomyal/sigma.js/blob/main/src/sigma.ts#L747) we would add a bit of extra logic to use those zIndexes to find if we have edges that should appear above any nodes and, if we do, isolate those edges and then render them after the nodes.
It's not a perfect solution as it doesn't provide full zIndex flexibility but it would at least give us the ability to have some edges over nodes. If zIndex is not set for edges or if the zIndex of all edges is less than or equal to the zIndex of all nodes than it would have no impact.
@Yomguithereal and @jacomyal - if I can write a proof of concept for the above would you be open to a pull request for it?
The text was updated successfully, but these errors were encountered: