Edge implementation duplication

[phenomnomnominal]

Describe the bug

As part of the performance improvements done to handle many edges, we had to introduce a split implementation. There is one for a small number of edges which can have animations, and one for a large number of edges which cannot have animations.

The current high perf implementation can either have animations or allow adding and removing nodes. Right now, the whole mesh is recreated when the list of nodes changes, so animating between the two sets of vertex positions is all over the place. Having both would require changing the implementation so that the mesh vertex indices remain stable as nodes are added/removed.

Steps to Reproduce the Bug or Issue

Look at the code

Expected behavior

One implementation for Egde

Screenshots or Videos

No response

Platform

• Reagraph Version: [e.g. 1.0.0]
• OS: [e.g. macOS, Windows, Linux]
• Browser: [e.g. Chrome, Safari, Firefox]
• NodeJS version: ...

Your Example Website or App

No response

Additional context

No response

[amcdnl]

This could potentially be useful: https://www.npmjs.com/package/@react-three/drei#performance

[amcdnl]

The goal of this ticket is to consolidate the edge rendering from 2 approaches into 1. Today the code forks if there are a high number of edges for performance reasons. It currently maintains the 2 branches because the high performance branch can't handle animations in its current implementation.

TLDR; drawing lines is expensive in webgl. If you can batch draw them ( i.e. all the edges in one mesh ) then you can improve the performance quite a bit. Problem is with the batch operation animating ( at least the way we are doing it today ) would be quite complicated ( if not impossible ). Also now you have 2 code points for similar logic which can create inconsistencies ( there are tickets rn around this ) and the code for the optimized edge is not easy to maintain/follow.

Here is where the logic breaks for each case: https://github.com/reaviz/reagraph/blob/master/src/GraphScene.tsx#L450

The solution to the ticket could be as easy as a fix in the current edge code to improve its performance removing the need for the batch rendering approach all together. The solution could be to double down on the batch rendering approach and remove the individual approach and figure out the gaps and solve those. It could also be to completely redo how this piece works all together, end of the day we just need 1 rendering.

[qdhenry]

Quick progress update #331

I've implemented the main consolidation work:

• Single rendering approach: Got rid of the dual edge implementation that was causing maintenance headaches
• Performance improvements: The smart edge promotion keeps large graphs (1000+ edges) running smoothly
• Consistent animations: Fixed the jarring mixed animation states - now everything respects the global animation setting

Current Issue: Temporary Arrow-Edge Disconnection
I'm still seeing brief visual separation between arrows and edge lines during state transitions. This affects several interaction patterns:
Highlight Interactions:

Hover → Inwards highlighting
Hover → Outwards highlighting
Hover → All highlighting

Selection Interactions:

Lasso selection (nodes and edges)
Node dragging during selection states
Multi-node selection scenarios

The root cause appears to be animation timing sync issues between the individual Line and Arrow components when edges get promoted/demoted during these transitions.