IVL is designed to be "window system neutral." That is, it attempts to avoid
duplicating capabilities that are typically supported by the native window
system (e.g., window operations, interactive input, color maps, and overlays).
The focus of IVL is to provide 2D imaging capabilities. By not including these
operations in the API, IVL can coexist with a variety of window systems.
However, the initial release of IVL is only available in the X Window System
environment. In order for IVL to coexist peacefully with the native window
system, a small number of window-system-dependent routines must be
defined. These routines provide implementation information, configuration
management, resource allocation/deallocation, synchronization, and other
window system dependent functions.
In the X Window System environment, IVL is supported by an X server extension
called GLX. This extension allows IVL to coordinate its
rendering operations with those of X and other extensions. The names of
routines in IVL that are specific to the X Window System environment are
prefixed with "glX."
The following figure shows a block diagram of the X/IVL environment:
The top of the above figure shows the application making calls to both Xlib
and IVL. These two libraries cooperate in sending commands to the X server via
a network connection. The boxes labeled "transport" indicate the network
transport mechanism that actually transfers X protocol requests between the X
client (the application) and the X server.
A dispatcher inside of the X server decides whether the request should be
handled by X itself or one of the available X extensions like GLX, which
supports IVL rendering and other operations. If the incoming command is an X
request, it is handled directly by the X server. Some of the X routines are
used to perform simple graphics operations and will cause the X renderer to
modify the contents of the frame buffer.
The biggest advantage of the X protocol is that it is network transparent.
This makes it easy to develop an application running on one machine that
communicates with an X server on another machine. However, the need to
transfer commands via some network transport mechanism can be a performance
restriction if the application and the X server run on the same machine (as is
often the case).
There are several ways that data can be transferred more rapidly between
processes if the processes are known to be running on the same system. IVL
provides a method for the application to directly access the frame buffer
hardware, provided that the application and the X server are running on the
same processor. Rather than going through the X protocol transport and the X
dispatcher, calls to IVL are converted immediately into commands that directly
access the frame buffer hardware. The improved performance that results from
direct hardware access is shown symbolically by the width of the arrow
(labeled "direct hardware access") connecting the IVL library and the IVL
renderer on the right side of the previous figure.
Application developers should note that this release of IVL only supports
local rendering. The ability for remote rendering with IVL across a network
connection is under investigation by HP, and may be supported in a future IVL
release. Direct (local) rendering (which is the highest-performance path for
IVL rendering) is available and optimized in the initial release.
Printable version
