Client and server side rendering

Another aspect that highly impacts on the performance and network load of such a system is the choice between rendering the visualization on the client or server side.

As described in Section 3.2, almost any current display device is based on 2D display panels or projection screens to display monoscopic (one image for one eye-perspective) and stereoscopic visualization (two or more eye-perspective images). Subsequently, the final result of a visualization creating process usually is a single or multiple 2D images. If these images are being presented at the location where they are being rendered, it is called a local or client side rendering. Vice versa, if the images are being presented at a remote location, it is called a remote or server side rendering. In the case of remote rendering, the visualization needs to be transferred via a network to a remote client computer, where it is then being displayed.

A natural but in terms of performance most determining functionality of interactive visualization systems is the modification of the visualization, as for instance to rotate, clip, pan, and zoom it.

Any modification command results in a modified image that needs to be presented. In the case of a local visualization, every newly rendered image is directly being displayed on the display device via a fast connection in full quality. But in the case of a remote visualization, each modified visualization needs to be updated to the remote computer via a disproportionally slower network connection almost always in reduced quality after compression. For a real-time access to the visualization, the user requires to view the modified visualization within a very short time frame after the control command was given. This time should be as short and unrecognizable as possible, which is usually within few milliseconds [7].

Both principles are illustrated in Figure 1.1 on page 5 with the data provisioning as central service.

The main advantages and disadvantages of client and server side rendering are summarized in Table 3.1. The following paragraphs describe the problems and prospects acompanied with client and server side rendering methods for sharing visualization with remote participants.

Client side rendering. A client side rendering requires every client to have a local copy of the base data and an application that handles the visualization rendering and synchronization with all other clients. Each client eminently requires proper graphics hardware that is sufficient to render the required visualization. If all participants need to work on identical visualization, each control command (e.g. requests to modify the visualization and system configuration) needs to be managed and synchronized.

The most apparent task of a client side visualization is the initial base data transfer to each client.

A fast 100 Mbps network connection allows to transfere a dataset of about 0.5 to 2 GB within about 1 to 3 minutes. But it may take about 7 to 27 minutes on a slower but more commonly available connection of 10 Mbps. Whereas a participant might wait 3 minutes in the first case, an initial waiting time of 30 minutes is unfeasible.

A multi-user access control management is necessary to allow only one participant to modify the visualization at any point in time. The synchronization of all clients is therefore unavoidable to provide every participant with the exact same view. Technically, this could be solved generically

Table 3.1. Server side versus client side rendering.

Type Advantages Disadvantages

Client side rendering

◦ Only control commands need to be transferred on a continuous basis

◦ The server does only have to provide data and manage the synchronization (in specific cases)

◦ A visualization session starts with a possibly large and long-lasting data transfer from the server to the clients

◦ The visualization session has no time-consuming initialization phase (e.g. base data transfer)

◦ The clients do not require special hardware

◦ The data stays on the server (more secure)

◦ State synchronization is less complex (client to server)

◦ The resulting raster graphics have to be transferred on a continuous basis to each client as soon as they are created; Therefore the network traffic of the whole visualization session is larger

◦ The delay between giving a control command and seeing the resulting visualization is larger (depending on the longer round-trip time to the visualization renderer)

3.3 Remote sharing of interactive visualization in real-time

on the level of the operating system by recording and distributing the mouse and keyboard commands of the modifying participant to any other client. But in order to have more control about the visualization, it could also be solved on the level of the specific visualization application, by keeping track and distributing all visualization parameters (e.g. camera positions and filters).

On principle, the data transmission could be done with both, star and mesh topology. If restricted to HTTP, however, any transmission needs to be done via the web server, which is a clear decision for a star topology. The absence of such synchronization would allow every client to interact in parallel on the same data, but different visualization views.

A real-time system requires the visualization algorithm to render the visualization result within few milliseconds to provide the user with the desired frame rate. Whereas the transfer of the control commands to the visualization application is negligibly short, the transfer to the remote clients causes a delayed rendering at the remote client. However, the data that is to be transferred is very small and, thus, a minor issue.

Transferring only the control commands to synchronize the visualization and not the visualization itself results in a low network load and allows for high frame rates on according workstations. In summary, a client side rendering has the main disadvantages of requiring a long lapse of time for the initial data transfer and high-performing computers for each participant.

Server side rendering. A server side rendering requires the server to have the data and the visualization application. The latter handles the rendering of the desired visualization and its continuous transfers to every client. Every client only requires a lightweight application to con-tinuously receive and present visualization images and to capture and send the control commands to the server. As a consequence, only the server requires to have access to the base data, which is a very basic kind of data security. The server requires to have proper graphics hardware to render the desired visualization and the client only basic hardware.

Whereas client side rendering requires a long initial time to transfer the base data, a server side rendering only needs about 8 to 80 ms to transfer each modified image with a size of 10 to 100 KB on a slow 10 Mbps network. These file sizes allow for a theoretical frame rate of about 125 to 12.5 frames per second (fps).

The base data might initially be stored on a data server (e.g. a PACS) and therefore might need to be transferred to the visualization server. However, both servers will likely have a static location (e.g. the same data center) and, thus, likely have a much faster interconnect. In any case, only the host of the visualization session (the participant who initiates it) in opposition to any participant might need to wait for this initial data transfer.

Whereas the client side rendering almost only depends on a fast local rendering, the server side rendering depends on a fast transfer of the control commands from and the visualization to the client. Therefore, the time for a single visualization modification is a summation of the time to transmit the command from the input device to the visualization application, the time to

render the visualization, and the time to transmit the visualization to and display it at the display device. By nature, the time to transfer the data from and the visualization to the display device is much higher with a remote than a local visualization rendering. Real-time Interactive visualization systems therefore highly depend on a fast transmission of control commands and the subsequently modified visualization.

A server side rendering also requires the management of the currently controlling participant, which is clearly done in the same network topology as the visualization transfer (star topology).

From using one visualization session with server side rendering follows that each client displays the exact same visualization. A second server instance with a second visualization session would have to be initialized, if one user needs to view a specific visualization asynchronous to the other clients.