Why would we want to do this? One, we may want our application to work on both X and Windows platforms. Two, we may want to support both OpenGL and IRIS GL (or PEX) during a transition period.
On the other hand, a complex application may be so tightly integrated with
a user interface toolkit or graphics library that it's impractical to support
alternative interfaces or libraries.
OpenGL, IRIS GL and PEX code is isolated into separate source files:
The core of Vis5Ds functionality is isolated from the user interface by
an internal API. Everything "below" the API is GUI independent.
Everything "above" the API is considered user interface code. While Vis5D's
user interface code is substantial, it could be replaced by an alternative
toolkit with minimal impact on the rest of the system.
The simplest solution to this problem is to only use functionality which
is common to all libraries. This can actually be quite practical in
simple applications which don't require elaborate renderering techniques.
The other solution is to poll the graphics system to determine its
capabilities and work around those it doesn't support. Vis5D, for example,
offers volume rendering only on systems with alpha blending capability.
If one is going to use multiple window systems (for example X/Motif and Win32)
it's best to first survey the GUIs to determine what they have in common
or what is unique to each.
It may be wise then to avoid using GUI features which can't be implemented
in all window systems.
The OpenGL window system interface (WGL, GLX) calls should be considered
window system code and not be put in the OpenGL modules.
This includes the swapbuffers operation.
2. Organization
The basics:
The practicality of this depends on the nature and size of the application.
One one hand, modern window system toolkits are quite similar in that GUIs
are designed with the callback/event loop paradigm:
Furthermore, rendering can be encapsulated in wrapper functions which
present a higher-level API which is independent of the graphics library.
3. An example: Vis5D
Vis5D is a system for interactive visualization of three dimensional
atmospheric data. It can use OpenGL, IRIS GL, or PEX for 3-D rendering.
An Xlib-based GUI toolkit provides the only user interface at this time
but it's quite feasible to write a new one.
Each file performs the rendering functions defined by a single header file,
graphics.h, defining functions such as:
which graphics.ogl.c, graphics.gl.c and grahics.pex.c each implements in
its own way. The Makefile determines which source file is compiled.
4. Graphics library functionality
When supporting multiple graphics libraries, a difficult problem to deal
with is subsetting. While OpenGL mandates that all its features be
implemented other graphics libraries aren't as stringently defined.
PEX implementations, for example, vary greatly in terms of what features
are implemented.
5. Multi-window system applications
Suppose your OpenGL application must work on several window system such as
X and Microsoft Windows.
How can this be accomplished?
5.1 Cross-platform GUIs
Consider using a cross-platform GUI such as GLUT or Tcl/Tk which is available
for several window systems.
GLUT is appropriate for demos or small applications.
Tcl/Tk is appropriate for any size demo or application.
Both are free.
5.2 Commercial porting tools
There are commercial solutions which provide Motif emulation for Windows:
Commercial solutions for porting Windows applications to Unix/X/Motif include:
5.3 Native support for multiple GUIs
Larger applications which use native window system toolkits will have to
be partitioned into modules which isolate window and operating
system-specific code.
Last edited on April 13, 1997 by Brian Paul.