Fix infinite loop in FruchtermanReingoldLayout.

[neilcsmith-net]

Quick fix for #8209 - an infinite loop with large dependency tree because isThereFreeSpaceNonFixedSpace() never returns true.

Only loop ~3 rotations. Increased force constant seems to improve result with reduced search.

[mbien]

@neilcsmith-net those issues can be likely closed with this PR
https://issues.apache.org/jira/browse/NETBEANS-1146
https://issues.apache.org/jira/browse/NETBEANS-2414
https://issues.apache.org/jira/browse/NETBEANS-3283
https://issues.apache.org/jira/browse/NETBEANS-4314
https://issues.apache.org/jira/browse/NETBEANS-5770

although the complete fix would also include to not do this on EDT - but this goes beyond a hotix

[neilcsmith-net]

although the complete fix would also include to not do this on EDT

That's unfortunately akin to trying to run a Swing layout off of the EDT. Might be OK to wrap in something like https://bits.netbeans.org/24/javadoc/org-netbeans-api-progress/org/netbeans/api/progress/BaseProgressUtils.html#runOffEventDispatchThread-java.lang.Runnable-java.lang.String-java.util.concurrent.atomic.AtomicBoolean-boolean-int-int-

[mbien]

That's unfortunately akin to trying to run a Swing layout off of the EDT.

yeah this shouldn't be done, the hope is that something in the computation can be detached from swing but I haven't looked into it so far. To get an idea I would:

• generate an async profiler flame graph to see the code paths which spend most of the CPU time during init (I still haven't progressed with my nb plugin which would make this easier)
• now check if the geometric data can be copied, computed asynchronously and then copied back into the swing data structure on EDT

if nothing helps or would make things too complicated I would:

• try to predict graph complexity by counting nodes, if there are too many nodes warn the user that the computation can take a while
• pause the computation every 15s and ask cancel/continue?