The X Virtual Frame Buffer Page 1 of 8

[ Bottom of Page | Previous Page | Next Page | Index | Feedback ]

AIXwindows Programming Guide

Appendix E. The X Virtual Frame Buffer

This chapter discusses the X Virtual Frame Buffer, an AIX feature that allows an application to
render into the main memory of the computer instead of the hardware graphics adapter. This
feature is also related to the hardware, because it can fully or partially replace the hardware.

Overview
The AIX X server has been enhanced to support the X Virtual Frame Buffer technology. The X
Virtual Frame Buffer (XVFB) allows the X server to initialize and run without the presence of any
physical graphics adapter. In the past, the X server required one or more graphics adapters in
order to run and would exit with an error if none were present.

Furthermore, in a standard X Window System environment, each 3D application running on a

system must share the same hardware frame buffer. While this is acceptable for viewing clients
locally, it is not acceptable for viewing clients remotely when the graphics windows overlap in the
screen space. This overlap causes rendering to be serialized and slows overall performance.

Using the XVFB, each application has a private 3D rendering area. Because there is no window
overlap, rendering can take place in parallel. The downside for any locally attached display is that
you cannot see the image on the screen; it must be displayed over the network to be viewed.

In the XVFB environment, an application renders images on a server machine. These images are
then distributed to viewing stations on a network, saved to a database, or used in some other
way. The XVFB environment is convenient for viewing 3D graphics on a low-end system for casual
users.

The XVFB software is supported by AIX 4.3 or later. The XVFB is also supported on the RS/6000
SP. Install the X11.vfb package, which requires approximately 1 MB of disk space. Make sure to
reboot the system after installing this package.

Installing the XVFB

This section describes how to install the software for the XVFB on various versions of AIX.

Note:
For all versions of AIX, a reboot is required after XVFB is installed before it can be used.

AIX 4.3
The XVFB for AIX 4.3 is installed from the following fileset:

l U454163 - OpenGL.OpenGL_X.dev.vfb.04.03.0000.0000

l U454162 - X11.vfb.04.03.0000.0000

Two PTFs are needed to fix a window resizing problem, but because they are not available, you
must migrate to AIX 4.3.1 or later to use the XVFB with AIX 4.3 .

If the PTF U452591 is installed, CATweb Navigator Version 1 runs successfully.

l U452591 - OpenGL.OpenGL_X.rte.soft.4.3.0.1

AIX 4.3.1

http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.aixwnpgd/doc/aix... 12/1/2009
The X Virtual Frame Buffer Page 2 of 8

The XVFB for AIX 4.3.1 is installed from the AIX 4.3.1 product CDs. Install the following filesets:

l OpenGL.OpenGL_X.dev.vfb.04.03.0001.0000

l X11.vfb.04.03.0001.0000

Two PTFs are needed to fix a window resizing problem and are available on fixdist:

l U456096 - OpenGL.OpenGL_X.dev.vfb.4.3.1.1

l U456079 - OpenGL.OpenGL_X.rte.soft.4.3.1.1

AIX 4.3.2
The XVFB for AIX 4.3.2 is installed from the AIX 4.3.2 product CDs. Install the following filesets:

l OpenGL.OpenGL_X.dev.vfb.04.03.0002.0000

l X11.vfb.04.03.0001.0000

AIX 4.3.3
The XVFB for AIX 4.3.3 is installed from the AIX 4.3.3 product CDs. Install the following filesets:

l OpenGL.OpenGL_X.dev.vfb.04.03.0003.0000

l X11.vfb.04.03.0003.0000

To get 8-bit pseudocolor support, install the following PTF, which is available on fixdist:

l U474006 - 4330-06 Recommended Maintenance for AIX 4.3.3

AIX 5.X
The XVFB for AIX 5.X is installed from the AIX 5.X product CDs. Install the following filesets
substituting the X with the actual version number:

l OpenGL.OpenGL_X.dev.vfb.05.0X

l X11.vfb.05.0X

Starting the XVFB

The XVFB is loaded into the X server with the -vfb flag:
/usr/bin/X11/X -force -vfb -x abx -x dbe -x GLX :n &

where n is the display number you wish to have associated with this instance of the XVFB. This
starts the X server without using any installed graphics adapter and loads the OpenGL extensions
to the X server.

The xinit command, which starts both the X server and the window manager, can also be used.
The xinit command looks for the display number immediately following the -- . If it finds no
display number in this position, it uses the default display.
/usr/bin/X11/xinit -- :n -force -vfb -x abx -x dbe -x GLX &

The syntax of the xinit command used for starting XVFB is the same as that used for starting a
normal Xserver. For more information, see the xinit command in the AIX Commands Reference.
The general form of this command is:
xinit [ [ Client ] Options ] [ -- [ Server ] [ Display ] Options ]

http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.aixwnpgd/doc/aix... 12/1/2009
The X Virtual Frame Buffer Page 3 of 8

Where Options for XVFB would need to include -vfb -force unless these flags were contained in
the xserverrc Server file. Note that all the commands l isted need to be on a single line.

For example, to start XVFB on display 11 using the default xinitrc and xserverrc files, type:
xinit -- :11 -vfb -force &

or, to start XVFB on display 11 using other client and server options, type:
xinit /Pathname /Client_Filename -- /Pathname/Server_Filename :11 -vfb -force &

Note:
The display specifier, Display, must precede the Options specifier. It will follow Server unless
Server is not specified in which case it will follow the --.
You can specify a window manager to use with XVFB. To start mwm with the -multiscreen
parameter, the command line would be similar to the following:
/usr/lpp/X11/bin/xinit /usr/lpp/X11/bin/mwm -multiscreen -- :n -vfb -force -x abx

If you need to start X with a window manager from the inittab, precede the command line with
Xvfb:2:once: or Xvfb:2:respawn: as shown by the example below:
Xvfb:2:once:/usr/lpp/X11/bin/xinit /usr/lpp/X11/bin/mwm -- :n -vfb -force -x abx

If you want to start the XVFB server by itself from the inittab with no window manager or default
client, you can use something like the following:
Xvfb:2:once:/usr/lpp/X11/bin/X : n -vfb -force -x abx -x dbe -x GLX &

The respawn entry causes the XVFB to start at system boot time and restart automatically if the
server exits for any reason. The once entry causes the XVFB to start at system boot only.

You can run more than one X server at a time, with the following restrictions:

l You cannot use the COSE Desktop.

l You may use multiple instances of the XVFB X server.

l You can use only a single instance of the X server running to a graphics adapter.

If you have a system with a graphics adapter, and you want to run one or more XVFB X servers
as well as an X server to your graphics adapter, do the following:

1. Start your X server to the graphics adapter:

/usr/bin/X11/xinit

2. From an xterm/aixterm, start your XVFB server:

/usr/bin/X11/X -vfb -x GLX -x abx -x dbe -force :n &

The display number n needs to be other than the one used with the graphics adapter.

Starting with technology level 4330-06, the XVFB can be started with depth 8 or depth 24 (24
is the default). To specify depth 8, include -d 8 on the command line. If the depth is 8, the
colorclass will be 3 (pseudocolor). If the depth is 24, the colorclass will be 4 (truecolor).
These are the only colorclasses supported for XVFB. Depth 8 is not supported for DirectSoft
OpenGL.

Note:
DirectSoft OpenGL does not support an 8-bit visual. An attempt to load the GLX extension
for an XVFB with depth 8 will fail and an error will be posted in the xlogfile file.

http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.aixwnpgd/doc/aix... 12/1/2009
The X Virtual Frame Buffer Page 4 of 8

To change the screen dimensions, add the following at the end of the command line used to start
the XVFB:
-I -screen S WxHxD

where W, H, and D are width, height, and depth and S is the screen number. For example, to set
1600x1200 at a depth of 8 bits for screen 0 and display 11 (an arbitrary number), the complete
command line would be as follows:
X :11 -vfb -force -x abx -x dbe -x GLX -I -screen 0 1600x1200x8 &

Only 8 and 24 bit depths are supported. The default screen dimensions are hard-coded at
1280x1024x24. The actual values can be changed as described above. The -dpi parameter is not
supported. For a physical display, resolution in dpi is fixed by the dimensions in pixels (for
example, 1280x1024) and the dimensions in inches. If you want to change the resolution, change
the dimensions in pixels. A vfb display has no physical dimensions in inches associated with it. It
can emulate a display of any physical size with any resolution (within bounds) by setting the
dimensions in pixels as appropriate.

The -sme option has been added in AIX 5.3. If you have a system with a graphics adapter, you
can run your X server with both the XVFB and the default graphics adapter where the XVFB
display will be the primary display. Replace -vfb option with the -sme option and remove :n.
/usr/bin/X11/X -force -sme -x abx -x dbe -x GLX &

The -sme option is not compatible with +xinerma option.

Testing the XVFB

Because you cannot see the frame buffer when using XVFB, it is difficult to confirm everything is
working correctly. Fortunately, several X clients ship with AIX that can be used to query and view
window contents, and can be used to help verify that XVFB is rendering the correct images. These
clients include xwininfo, xwd, and xwud.

Verifying that XVFB is Being Used

To verify that an X server is running with the XVFB, use the following command:
/usr/lpp/X11/Xamples/bin/xprop -display sysname:n -root | grep VFB
XVFB_SCREEN(STRING) = "TRUE" <== indicates XVFB is being used

where sysname is the system name and n is the display number for which you are inquiring.

Verifying that XVFB is Working

If you are unsure whether XVFB is installed and started correctly, use the following method to
test XVFB. Your system must be on a network and you need access to another system (with a
screen) to view the contents of the XVFB.

1. On the XVFB system, start the X server using the -vfb flag:
/usr/lpp/X11/bin/X -force -vfb -x GLX -x abx -x dbe :n &

2. On the XVFB system, run the xclock client program:

xclock -display :n &

3. On the other system, make sure X is running and that clients can connect:
xhost +

http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.aixwnpgd/doc/aix... 12/1/2009
The X Virtual Frame Buffer Page 5 of 8

4. On the XVFB system, find the window ID for the xclock client:
xwininfo -root -tree | grep xclock

The first number (0x12345678) is the window ID.

5. On the XVFB system, use xwd/xwud to display the client window of the XVFB system on the
other system.
xwd -id 0x12345678 | xwud -display othersystem :0.0

An image of the xclock you started on the XVFB system displays on the other system.

Implementing XVFB in Application Code

XVFB allows developers to write Web-based 3D graphics applications for an RS/6000 server
without the need of a 3D graphics adapter. In most environments, XVFB-enhanced applications
can achieve near-linear scalability by adding processors to multiple-processor systems, because
each client can render into its own frame buffer without interaction with the X server. Users
viewing data at client systems receive the benefit of XVFB with no changes to software or
invocation methods to applications. For an application to operate in a XVFB environment, the
application must be enhanced in the following way:

1. To extract a rendered image from a rendering server:

Extract or retrieve the image to be displayed from the rendering server. Typically, an
application would do an XGetImage for X applications or a glReadPixels for OpenGL
applications. The application decides the frequency and type of actions that will result in the
extraction of the image from the rendering server. One criteria might be each time the buffer
is swapped using the XdbeSwapBuffers or glXSwapBuff er subroutine.

2. To send commands to a remote application on a server platform:

To give the application input to perform, such as opening files or transforming objects, there
should be a method to send the application input from a remote source. This can be a
command language, a socket connection, interaction with an HTTP server, or some other type
of communication services. The XRecord and XTest extensions can be used to send events
to the X server and communicate with the application through traditional X events.

3. To display an image on a display station:

The XVFB environment should contain a method to display the rendered image on the display
station. The method of display of the extracted image is at the discretion of the programmer.
If the display station is an AIX workstation executing an AIXwindows X server, the extracted
image could be displayed using the xwud command. The xwud command takes an image in
the xwd format, creates a window, and does an XPutImage to display the extracted image.

More sophisticated methods could include image compression and Java display applets. The
advantage of a Java display applet is that the image could be displayed on a variety of
platform types.

Applications can also check for the value of the XVFB_SCREEN property to determine if they
are running with the XVFB. The following code shows how this can be done:
int isXVFB(Display *display,Screen screen)
{
Atom atom,actual_type;
int actual_format,status;
unsigned long nitems,bytes_after;

http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.aixwnpgd/doc/aix... 12/1/2009
The X Virtual Frame Buffer Page 6 of 8

unsigned char *prop;

atom = XInternAtom(display,"XVFB_SCREEN",True);
if (atom == None)
return False;
status = XGetWindowProperty(display,RootWindow(display,screen),
atom,0,100,False,atom,&actual_type,&actual_format,&nitems,
&bytes_after,&prop);
if (strcmp((char*)prop,"TRUE") == 0)
return True;
return False;
}

Working with the XVFB

The XVFB works by providing an X Device-Dependent X (DDX) layer that drives a software
graphics adapter. The frame buffer is stored in system memor y and all graphics processing (lines,
polygons, text, and so on) is done in the software using the system CPU.

The XVFB is intended to be used in a "rendering server" environment. With XVFB, X applications
can run and render images, and the images can be queried back into the application for saving to
a file, distributing across the network, saving to a database, an d so on. In this mode, the X
application is not being used directly by a user in an interactive way. Instead, the X application is
being driven remotely as a rendering server.

With no physical graphics device, no RAMDAC (random access memory digital-to-analog

converter) exists to generate RGB signals. Therefore, it is impossible to connect a monitor to your
system and view the contents of the X server Virtual Frame Buffer. This situation is a good
solution for rendering server environments, where the added expense of a physical graphics
adapter and display are not required. When you cannot see the X frame buffer directly, it does
make debugging your application more difficult. It is suggested that applications be developed
with a physical graphics adapter and then ported to the XVFB. X client tools like xwininfo, xwd,
and xwud can be used to help verify your application is running correctly with the XVFB.

Input devices in the XVFB environment are not required. Because you cannot see the frame
buffer, moving the mouse around and typing on the keyboard are not very useful. Rendering
server applications are driven remotely with direct socket communication, interaction with an
HTTP server, through CORBA connections, message passing interface (MPI), or other methods.
Most applications need modifications in order to be controlled remotely for a rendering server
environment.

OpenGL is currently supported with the XVFB; however, PEX, GL 3.2, and graPHIGS are not.

DirectSoft OpenGL and the XVFB

DirectSoft OpenGL (DSO) has been implemented to work with the XVFB and was design ed
specifically to enhance CATweb server performance by:

l Eliminating extraneous interprocess communication

l Eliminating process context-switching overhead

l Making rendering and image reading more direct and efficient.

DSO is a pure software implementa tion of OpenGL that runs as a direct OpenGL Context.
Therefore, all of the CPU-intensive OpenGL work (3D rendering) is part of the application process,
not part of the X server process. By running direct, all of the interprocess communications with
the X server are eliminated, making 3D rendering much more efficient. As a result, the AIX

http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.aixwnpgd/doc/aix... 12/1/2009
The X Virtual Frame Buffer Page 7 of 8

operating system does not have to perform context switching between the X server and the 3D
rendering applications, making system utilization more efficient.

DSO and XVFB enable SMP machines as viable and scalable CATweb servers. DSO creates a
private rendering area for each 3D rendering application. When it is time to render a new image,
the application draws to its private rendering area. If two CATweb clients request new images at
the same time, each of the 3D rendering applications can draw new images concurrently, each to
their own private rendering area. Because multiple 3D rendering applications can draw
concurrently, multiple CPUs can be exploited concurrently. Without DSO and XVFB, the 3D
rendering applications draw to a physical, shared frame buffer, which means they must take
turns and operate serially. With each 3D rendering application taking turns to draw, only a single
CPU can be effectively exploited.

If you use an OpenGL application with DirectSoft OpenGL and XVFB, the testing scenario with
xwd and xwud discussed earlier in this chapter will not work. This is because to increase
performance, the default OpenGL DirectSoft behavior does not blit the contents of the private
frame buffer to the X Virtual Frame Buffer. This behavior is fine for most OpenGL rendering
server applications because the image will be queried from the private frame buffer using
glReadPixels. However, using xwd and xwud just grabs the contents of a blank window.

To verify that DirectSoft OpenGL is working, set the _OGL_MIXED_M ODE_RENDERING

environment variable to 1, and run your OpenGL application. This will force OpenGL to actually
blit the rendered image from the private software frame buffer to the X Virtual Frame Buffer.
After this is done, you can use xwd and xwud to grab and dump the contents of your OpenGL
window.

Note:
It is recommended that you not keep the _OGL_MIXED_M ODE_RENDERING environment
variable set all the time, because this will slow the overall operation of DirectSoft OpenGL.

Applications can determine if they are using DirectSoft OpenGL by checking the OpenGL
rendering string using the glGetString subroutine, and checking the OpenGL context using the
glXIsDirect subroutine. The following code can be used:
int isDirectSoftOpenGL(Display *display,GLXContext context)
{
if (glXIsDirect(display,context) == FALSE)
return FALSE;
if (strcmp(glGetString(GL_RENDERER),"SoftRaster") == 0)
return TRUE;
return FALSE;
}

CATweb and the XVFB

CATweb Navigator allows users with Java-enabled Web browsers to view and navigate product
information created with CATIA Solutions. By using the intuitive set of Java applets that make up
the CATweb Navigator client, users can connect to a CATweb Navigator server machine, select
models for viewing, and then view and navigate the models with a 3D viewer, 2D schematic
viewer, or a report-style viewer. One CATweb Navigator server machine can support multiple
concurrently active CATweb Navigator clients. For each CATweb client that attaches to the
CATweb server, one or more CATweb processes is started on the CATweb server to handle the
requests of that particular CATweb client. One of these CATweb processes is a 3D rendering
application, which runs on the CATweb server and is responsible for:

l Loading the requested CATIA model

l Rendering the 3D model when the CATweb client requests new views

http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.aixwnpgd/doc/aix... 12/1/2009
The X Virtual Frame Buffer Page 8 of 8

l Compressing the final rendered image

l Transferring the image to the Java CATweb client

This application uses both the X Window System and OpenGL libraries to quickly and accurately
render 3D images. XVFB and DirectSoft OpenGL allow CATweb Navigator server machines to
operate without expensive graphics adapters and to effectively exploit Symmetric Multi
Processing (SMP) machines. In addition, XVFB and DirectSoft OpenGL allow a CATweb Navigator
server to be usable at boot time without requiring a user to log in interactively, making it easier
to set up and administer a CATweb Navigator server.

The CATweb Navigator does not use the XVFB by default. The image server rendering is done
through the X real frame buffer and all the concurrent CATweb renderings are synchronized to
share this single resource (CATweb rendering lock). In the XVFB mode, each CATweb process
uses its own X Virtual Frame Buffer, and the rendering synchronization is no longer necessary,
improving the overall performance in a multi-user environment.

To deactivate the default CATweb rendering lock, change the following value in the
runServerCATIA file in the .../CATwebNavigator/bin directory :
VirtualFrameBufferOn=1 (default value = 0)

The CATweb rendering unlock is effective at the next CATweb connection.

[ Top of Page | Previous Page | Next Page | Index | Feedback ]

http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.aixwnpgd/doc/aix... 12/1/2009