The new Kalileo release is rich of interesting features. We have been working especially on resolving some performance and aesthetics issues. In this blog ticket, we will give a concise overview of some of these features.
Many customers have expressed their satisfaction on the rendering and layout speed of large graphs. But, when speaking about basic interactions with such graphs, they noticed the low speed and lagging effects especially when panning which is the most basic interaction with huge diagrams.
Before speaking about the solution we have included, it is obvious to precise the meaning of a huge graph from Kalileo consideration and with respect to Flash Display List limitations. A huge graph is a graph containing more than 1000 elements including nodes and links (without consideration of decorators). The number definition may be doubled when using Sprite based elements on any components of the Kalileo product. From such definition, any Flex/Flash developper can deduce that changing the position of each of these elements at once and at each mouse move event leads inevitably to performance problems. In order, to get rid of these repetitive displacements and their performance impact, we have added a bitmap panning option on the PanAction via its PanActionData (enableBitmapPan property). When activating this option, on each panning action start (Mouse Down event), a bitmap of the Visualizer is computed, all graph artifacts are made invisible to let the user pan the Bitmap exclusively to the chosen position (Mouse Move event). At position validation (Mouse Up event), the computed Bitmap is deleted from the DisplayList to show and validate the new positions of the graph elements. The result is very interesting and we think that such solutions may be extended to some other interactions (Zoom, Node displacement with huge link dependencies....).
Flow diagrams are generally organized via the Hierarchical Cyclic Layout for the best aesthetic representation. The previous versions of Kalileo have some aesthetic issues when combining link anchoring, edge crossing minimisation and Hierarchical Cyclic Layout. In the research field, this kind of problem is addressed via link routing techniques that can lead to serious performance falls especially when performing these computations on a Web context.
Considering these facts, we have enhanced our layout with:
- Better support of anchors when computing an edge's path via a proprietary local node routing. The aesthetic result is not optimal but can be considered as a good deal between performance and aesthetics;
- Consideration of link anchoring on nodes when dealing with edge crossing minimization problem;
- Support of overlapping links' segments separation on both orthogonal and free links' shape.
In many use cases (BPM, UML...), diagramming experience needs to integrate algorithms to avoid links overlapping with nodes or links segments. These algorithms are generally considered as Edge Routing algorithms.
In the previous versions, a general edge routing algorithm has been proposed and acts on the whole graph. But, as we are aware of our customers needs, we have noticed the need of live edge routing meaning that any new created link need to be routed to minimize overlapping with all the other graph elements in a pseudo-immediate manner. Thus, we have provided several methods to perform routing directives pragmatically. A great enhancement has been also performed on the LinkAction behavior and customization level with:
- the support of link routing with respect to anchoring constraints;
- the support of live routing at link creation time (via enableRouting on the routingParam of LinkActionData) and event at link pre-creation when the user moves the ghost link (via enableDynamicRouting on the routingParam of LinkActionData);
- the ability to automatically nudge overlapping link segments for more visibility. This feature can be activated or not within routing via (enableNudging and enableDynamicNudging on the routingParam of LinkActionData);
- the auto-assignment of link extremities anchoring if the source or/and the target have anchors with respect to the created link shape.
We are aware that edge routing algorithms are continuously enhanced and we will be following these enhancements.
Besides, links extremity and anchoring can be modified by the user by just dragging the extremity to target/source node of your choice or to the requested anchoring position. This behavior can be totally customized and live link routing is also supported on the ExtremityChangeAction via its ExtremityChangeActionData.