Performance Issue with _setDroppablesActive in Katavorio.js

[nikhilkataria-salesforce]

I am using jsPlumb to create 200 to 300 nodes on the canvas. After the initial rendering of nodes and connections, If I try to draw a connection from source to target I see there is a lag in seeing the actual connector move with my mouse pointer.
After doing a bit of digging I found out the lag is happening because of the following : as soon as I select the sourceEndpoint and move my mouse, in katavorio.js "this.moveListener" is called, which calls the this.mark function which in turn calls the _setDroppablesActive which is basically a foreach over all the node elements in my canvas, since I have not defined any scopes.

e.setActive(val) adds a class "jtk-drag-active" to all the node elements in the canvas which is super slow(causes noticeable lag) for anything above 150 + nodes.

[sporritt]

do you have any suggestions for what could be done to change this?

[sporritt]

a single jtk-drag-active on the container perhaps

[nikhilkataria-salesforce]

#41 the PR gives a workaround for making the droppables active a config rather than setting it active all the time.

A single jtk-drag-active drag active will probable not work because it might affect the scope functionality in jsPlumb. I am guessing the only the things belonging to a particular scope should be made active and hence it was done the way it is right now in code.

A permanent solution might be checking if its part of the scope once the mouse enters a particular node/source/target area instead of doing it on mouse move listener.

[sporritt]

A single drag active class would affect the scope functionality in jsPlumb, yes. And that is indeed why the code is how it currently is.

Regarding the mouse enter solution you mentioned, the active class is assigned at the beginning of a node drag; it isn't a hover thing.

I've been thinking about this since I wrote that first comment about the single drag active class. It would be possible to add the current scope as another class to the drag active stuff, ie. the container could get jtk-drag-active jtk-drag-active-myscope instead of jtk-drag-active. For the majority of use cases, which do not make use of scopes, this would remove the performance hit and people could simply attach styles to jtk-drag-active. For use cases where there are scopes it would be necessary to write css rules to cater for each of the scopes, of course, but that's probably not a disaster.