Update Network to use Cell.position and layout for Visualisation#3345
Update Network to use Cell.position and layout for Visualisation#3345
Network to use Cell.position and layout for Visualisation#3345Conversation
|
|
||
| if isinstance(self.space, OrthogonalGrid | VoronoiGrid | ContinuousSpace): | ||
| if isinstance( | ||
| self.space, OrthogonalGrid | VoronoiGrid | ContinuousSpace | Network |
There was a problem hiding this comment.
how does this work if we don't assign positions to network inside the model? Is it still possible to handle this in the visualization or not?
There was a problem hiding this comment.
how does this work if we don't assign positions to network inside the model?
It won't
Is it still possible to handle this in the visualization or not?
Honestly I need to explore the visualization side a bit more, once #3323 is merged, I will explore it bit further if that's okay.
There was a problem hiding this comment.
I am also fine with requiring this at the model level across the board. In my view, this would be in line with the idea of a Locatable protocol.
|
Performance benchmarks:
|
|
The tests are breaking on the network change. Can you take a look? |
|
Something is definitely going wrong with Networks Screen.Recording.2026-02-20.191738.mp4I am working on it but any inputs will be highly appreciated |
|
Hi @quaquel, After digging into these edge cases, they all trace back to a single root cause: handling topological networks where Currently, the visualization layer is forced to do the heavy lifting to translate I see two options for when a user initializes a Network with
What are your thoughts? |
I agree and I am inclined to use a meaningful default if no position is provided. Not sure what that default should be. In my view it should be very cheap to calculate for large networks. So something like a circle layout might be sufficient. As long as this behavior is well documented, I think this is the best way to go. |
Agree. circular_layout is the perfect choice |
codebreaker32
force-pushed
the
fix_space_renderer
branch
from
c271fc9 to
b587df1
Compare
codebreaker32
force-pushed
the
fix_space_renderer
branch
from
b587df1 to
62949c7
Compare
codebreaker32
changed the title
_map_coordinates in SpaceRendererNetwork to use Cell._position and layout for Visualisation
codebreaker32
changed the title
Network to use Cell._position and layout for VisualisationNetwork to use Cell.position and layout for Visualisation
|
This PR is ready for review and can be merged after #3355 as discussed |
2 participants
This PR updates
space_renderer.pyto treat Network spaces as direct position-based systems, aligning their rendering logic with OrthogonalGrid, VoronoiGrid, and ContinuousSpace.Changes:-
It decouples the visualization backends from NetworkX layout calculations. Because
cell.positionis now guaranteed, all dictionary lookups,np.uniqueID mapping, and fallback layout algorithms were removed from the visualization layer.Networkspaces now use the same highly optimized, direct coordinate pass-through asOrthogonalGridandContinuousSpace.Deleted obsolete tests that were checking the legacy dictionary lookup and missing-node warning logic, and updated coordinate mapping assertions.