To understand some of the visualization design choices, the flexibility aspect has to be seen in detail. The aim of flexibility is part of any big software products, so it is also part of Gephi’s visualization module. In this article the evolution of software architecture is discussed and the existing solution of the visualization module is presented.
The objective is always the same, maximize change and minimize architecture adaptation. Although minimum coding is also an objective, it doesn’t cause such problems as with architecture. When you realize what you want to achieve is completely incompatible with the current architecture you have to break the compatibility. This may have effect in all modules and require a lot of effort. For instance the current Gephi architecture is not suited for supporting clustering, so we had to think again some systems from the root.
With a flexible architecture one expect architecture change, but in accord with the long-range planning.
If the flexibility is about architecture, what really characterize a flexible architecture?
From a technical point of view, a flexible architecture allows to add new functionalities easily. Code is reused and all advantages of object-oriented programming is taken, like design pattern. When a flexible architecture is also a modular one, this allows easy move from a type of architecture to another. That said, it depends a lot from what technologies you’re using and level of liberty you dispose.
On an upper level, what is even more important is a clear architecture, well structured, readable code and documentation. Keeping an overview on the whole system finally makes developer’s decision better. If this is lost, I assume it’s very difficult to ensure both backward compatibility and new functionalities. But who cares about backward compatibility? 😉
The visualization module is an important part of Gephi. Because long-range plan exists, a flexible architecture could be achieved. But the module has also heavy efficiency requirements. As I said in a precedent article it is difficult to have both flexibility and efficiency in the same time.
Some other graph visualization software can draw a lot of different graph like UML, processes or diagrams. Drawing all of these different objects in an efficient way is almost impossible, especially in 3D rendering. Hopefully Gephi concentrates only on network visualization. So the number of objects is limited: nodes and edges on the first place.
Here is an outline on what is already achieved:
* The complete display engine is reusable: To ensure graphic card compatibility, several render engines can be used and the engine with the best compatibility is chosen. This is necessary to be free to implement new technologies very quickly. For instance we plan to develop in 2009 a second graphic engine, using new Shaders technology.
* Separate the engine from objects to render: This point is prevailing, in order to support new things to render. Each type of objects doesn’t need the same care, so let them have their own initializer classes, a bit like the decorator design pattern.
* Avoid event-driven architecture because it becomes too complicated with multi-threading.
Different objects in different classes need to be displayed by the visualization module. All of this has to be dynamic in order to allow plugins to add their own object types. Hence there are two packages, the objects themselves and related initializers. They provide what object need. For instance, some objects will need LOD (Level-of-detail) or some other texture functionalities.
Objects type can be changed from the Properties dialog. Right click on the graph and then Properties…
Here are the current object types supported by Gephi:
Standard geometric forms, these are the most efficient to render. Sphere is enabled by default.
The Panel is very special. Visually it is a texture but in real it exists as a JPanel. This is the standard Java interface panel here you can put anything (labels, forms, table, charts, images…). The dedicated initializer transforms the JPanel into a texture that display engine can render. This object is really the pedestal of the variety of objects possibilities.
The attributes panel. This is an example of Panel implementation. When nodes are initialized a JPanel is created with a list of the node attributes value. Then this panel is automatically converted in the drawable object.
The Image panel. Also an implementation of the panel, it simply takes an image URL in nodes attributes. The image is then automatically downloaded and set on the panel. It can also work with images stored on the hard drive or sent through a data-source.