A main purpose of Grid technology has always been to enable high performance computing applications, such as simulations and visualization of their outputs. The power of computational visualization arises from the ability of providing interactiveness for the user to permit changes of visualization and simulation parameters. By demanding real interactivity, some very tight constraints in terms of response time have to be satisfied, which requires a corresponding amount of computational power and network connectivity. The former is provided by the Grid, the latter can be achieved by adapting the communication to available network bandwidths. When porting a visualization pipeline to the Grid, one has to decide where to split the pipeline and how to distribute the different visualization tasks onto the different, possibly dislocated, resources benefiting from parallelism or their specific capabilities. GVid executes all the visualization tasks except the final display on the Grid. Only an efficiently and thus highly compressed video stream is transferred through the network and displayed on one or more thin video clients, while the feed back is from a single master user, who interacts with the application.

GVid falls into three main parts which are shown in figure below. The input adapters, which act as an interface to the visualizing applications and perform the video encoding, the transport modules, which allow different mechanisms to be used within GVid, and the thin output client, which decodes and displays the images created remotely.

• Input adapters
  • RemoteGLUT, a modified implementation of FreeGLUT, which acts like the original version of the library, but performs offscreen rendering instead, using a hardware accelerated extension of OpenGL where available or pure software rendering through OSMesa. This library allows remote rendering transparently for any application using GLUT.
  • VTK-GLUT, modules for VTK (The Visualization Toolkit), which are based on the above modules, for direct integration with VTK. Every VTK application using this modules will render to a remote target, using GVid.
  • XWin-GrabServer, a generic X11 window grabber as sort of fallback mechanism if applications use an arbitrary rendering library or their source code is not available. Using this kind of module needs the remote application to be enabled to render to a visible, non obstructed window on the remote system.
• The Transport layer
  • Files and special-files like Posix-pipes are a very convenient way of interfacing information. Both GVid input and output adapters can use this way to communicate with each other, and remote shells like glogin or ssh are used to connect the two GVid counterparts together. The security of the transmitted data is left to the chosen underlying transport, like it is done when using GVid in the Grid with glogin and GSS encryption as transport mechanism.
  • Plain Unix or TCP sockets can be used for letting the endpoints of GVid directly communicate over the net. The video codec has to care about encryption on its own, using this approach.
• Output adapters are the final interface to the user displaying the decoded video data and capturing the user's interaction, feeding it back to the rendering application. Currently there is a client (SDL output client) for standard PC compatible hardware running either Microsoft Windows or any Linux distribution.

For more information please refer to http://www.gup.jku.at/research/projects/gvid