3.6. THE VISUALIZATION 39 the visual objects to define their size in the timeline.
Figure 3.10 – Representation of State and Link Visual Objects in the 3D scene.
Another characteristic of the 3D scene is the visualization base. As previously discussed, we created three different configurations that are rendered in the base. Next Section details how the three different cases generated by the entity matcher are rendered in the 3D scene. The Section 3.6.2 presents the possible interaction mechanisms that can be applied in the 3D scene.
3.6.1 Rendering the Visualization Base
Figure 3.11 shows how the communication pattern is rendered in the visualization base. As input, the visualization component (D) has on its left the visual objects, which are composed of links and entities in this example, and on its bottom the communication pattern generated by the entity matcher. On the right of the Figure, the scheme shows how the visualization of the communication pattern on the base is rendered. The vertical bars are the states of the processes through time.
Figure 3.11 – The representation of the communication pattern in the 3D Scene.
Still on Figure 3.11, we can notice that the links among the processes are undirected. In real situations, the trace data can have information about the origin and destination of a certain communication. This data, together with the set of other communications may enable a more complete representation of the communication pattern. The visualization component is able to
enhance the definition of the positions for every process trying to avoid crossing links, improving the perception and understanding of the communication pattern. Another possibility appears when there are several communications between two processes for a given interval of time.
The visualization component, in these cases, can generate a visualization where the width of a connection in the visualization base will be larger for pairs that communicate more.
Figure 3.12 shows the second configuration of the entity matcher, composed of the network topology and the communication pattern. The component has as input the flow of visual objects, on the left, and the network topology (represented by the darker and larger lines) on the bottom.
The 3D scene is on the right, with the visualization base holding the network topology and the communication pattern. The states represented in the timeline are in the Figure only for information purposes. The links were not drawn in the schematic 3D scene.
Figure 3.12 – The representation of the network topology and the communication pattern in the 3D Scene.
The second configuration for the visualization base (Figure 3.12) is especially important when network-bounded parallel applications are analyzed. In these cases, the representation can be improved with additional information such as the bandwidth and latency for each link. This combination of characteristics from the network may help the detection of possible communica-tion bottlenecks caused by extreme utilizacommunica-tion of one network link, for instance. The represen-tation in the base can be altered to show larger width for network links with higher bandwidth, and different colors to represent latency information in a given time. If routing information is also present, the user may observe which path the messages took during the execution, enabling the analyst to view if an alternative deployment of process would result in benefits in terms of execution performance.
The representation of the third configuration of the base is depicted in Figure 3.13. The logical organization of the components, generated as a hierarchy and represented with a treemap by the entity matcher, is drawn on the base by the visualization component. The resulting scene appears on the right of the Figure. As previous configurations, the representation includes the states representation in the timeline just to show a view of what the 3D scene would look like.
Links in the visualization base were removed from the example in order to focus on the treemap generated by the entity matcher. This representation serves mostly as statistical summaries of the application that are rendered in the same scene that detailed behavioral events. The rectangles in the base, that normally represent resources, can be calculated following several characteristics of
3.6. THE VISUALIZATION 41 the application behavior, such as the number of communications, their size, the amount of time in a given state and combinations of these. The work of customizing this representation to different needs must be done through a cooperation between the entity matcher and the visualization component, since the former has hierarchical information about the organization of the resources and the latter has timestamped visual objects, such as states.
Figure 3.13 – The representation of the hierarchical logical organization in the 3D Scene.
The rendering of the treemap in the visualization base has some peculiarities that must be taken into account. The first one is related to the size of the main square used in the repre-sentation. This size is usually defined by the user, but in cases where an increasing number of resources is present, it would be interesting to see the size of the main square increasing auto-matically. Considering that the 3D space is unlimited, this size could become too big to generate an easy understanding of the representation. To solve this situation, aggregation and reduction mechanisms should be used to downscale the quantity of data that is drawn. The aggregation mechanism that is presented in next Chapter could be applied here.
Another characteristic of the treemap visualization base is when the squares represent ma-chines, for instance. If there are too many processes in the same machine, the visualization will result in a larger number of processes that must “fit” in a given square. If the square is too small, the resulting alternatives are either to aggregate the processes in one entity, or to increase the size of the main square of the treemap. Both alternatives have their drawbacks and benefits and must be balanced to provide an aesthetic visualization to the end user of the 3D representation.
3.6.2 Interaction Mechanisms
The 3D visualization also comes with a number of different interaction mechanisms. Some of these mechanisms were already discussed in Section 3.1. Here, we investigate a step further by giving more details and exploring some examples. First of all, we must first remind of the notion of camera inside the scope of the 3D representation. The visual conception of the 3D approach, described in this Chapter, expects the presence of a camera. This artifact must be present because it is from this viewpoint that the visualizations are created.
Different mechanisms can act on the camera. The first and more relevant is translation operations inside the 3D space. The translation of the camera position allows the camera to go forward and backward through time, for instance. Besides, the camera can also be rotated in the
three axis to give the analyst other viewing angles. Figure 3.14 shows how these mechanisms act to provide different points of view. The first image at left is a replica of the image depicted in Figure 3.12. Subsequent images to the right show the point-of-view from different angles of the same scene.
Figure 3.14 – Different points of view of a 3D scene, generated with camera translation.
Other possible interaction mechanisms of the 3D approach is the use of animations and replays. Animations can be used to give the analyst the possibility to analyze the chain of events step by step, viewing the representation of every event one at a time. The dynamic of the animation can also help the observation of repeating patterns during the events evolution. These animations can be combined with the replay technique, showing again specific intervals of time.
Classical interaction mechanisms already present in other visualization tools can also be applied in the 3D approach. Zoom, for example, can be applied by changing the time scale rendering in the timeline, allowing a more detailed analysis when zoomed, and general views of the whole scene when the user has a more significant time slice rendered in the scene. The changes in the time scale can also lead to performance improvements in the way the visual objects are stored. In general views, much of the details that are rendered could be discarded without losing the major understanding of the events.