OpenGL : Interaction
The model for interpretation of OpenGL commands is client-server. An application (the client) issues commands, which are interpreted and processed by OpenGL (the server). In this sense, OpenGL is network-transparent. A server can maintain several GL contexts, each of which is an encapsulated GL state. A client can connect to any one of these contexts. The required network protocol can be implemented by augmenting an already existing protocol or by using an independent protocol. No OpenGL commands are provided for obtaining user input.
Check this slide deck for more information.
The effects of OpenGL commands on the frame buffer are ultimately controlled by the window system that allocates frame buffer resources. The window system determines which portions of the frame buffer OpenGL may access at any given time and communicates to OpenGL how those portions are structured. Therefore, there are no OpenGL commands to configure the frame buffer or initialize OpenGL. Frame buffer configuration is done outside of OpenGL in conjunction with the window system; OpenGL initialization takes place when the window system allocates a window for OpenGL rendering.
Display Lists :
A display list is simply a group of OpenGL commands that has been stored for subsequent execution. The glNewList() command begins the creation of a display list, and glEndList() ends it. With few exceptions, OpenGL commands called between glNewList() and glEndList() are appended to the display list, and optionally executed as well. To trigger the execution of a list or set of lists, use glCallList() or glCallLists() and supply the identifying number of a particular list or lists. You can manage the indices used to identify display lists with glGenLists(), glListBase(), and glIsList(). Finally, you can delete a set of display lists with glDeleteLists().
GLUT :
The OpenGL Utility Toolkit (GLUT) is a programming interface with ANSI C bindings for writing window system independent OpenGL programs. The toolkit supports the following functionality:
- Multiple windows for OpenGL rendering.
- Callback driven event processing.
- Sophisticated input devices.
- An “idle” routine and timers.
- A simple, cascading pop-up menu facility.
- Utility routines to generate various solid and wire frame objects.
- Support for bitmap and stroke fonts.
- Miscellaneous window management functions, including managing overlays.
Background :
One of the major accomplishments in the specification of OpenGL was the isolation of Window System dependencies from OpenGL’s rendering model. The result is that OpenGL is window system independent. Window system operations such as the creation of a rendering window and the handling of window system events are left to the nativewindow system to define. Necessary interactions between OpenGL and the window system such as creating and binding an OpenGL context to a window are described separately from the OpenGL specification in a window system dependent specification.
Removing window system operations from OpenGL is a sound decision because it allows the OpenGL graphics system to be retargeted to various systems including powerful but expensive graphics workstations as well as mass-production graphics systems like video games, set-top boxes for interactive television, and PCs.
Unfortunately, the lack of a window system interface for OpenGL is a gap in OpenGL’s utility. Learning native window system APIs such as the MFC, QT or X Window System is daunting task.
GLUT is designed to fill the need for a window system independent programming interface for OpenGL programs. The interface is designed to be simple yet still meet the needs of useful OpenGL programs.
GLUT simplifies the implementation of programs using OpenGL rendering. The GLUT application programming interface (API) requires very few routines to display a graphics scene rendered using OpenGL. The GLUT API (like the OpenGL API) is stateful. Most initial GLUT state is defined and the initial state is reasonable for simple programs.
The GLUT routines also take relatively few parameters. No pointers are returned. The only pointers passed into GLUT are pointers to character strings (all strings passed to GLUT are copied, not referenced) and opaque font handles.
The GLUT API is (as much as reasonable) window system independent. For this reason, GLUT does not return any native window system handles, pointers, or other data structures. More subtle window system dependencies such as reliance on window system dependent fonts are avoided by GLUT; instead, GLUT supplies its own (limited) set of fonts.
For programming ease, GLUT provides a simple menu sub-API.While the menuing support is designed to be implemented as pop-up menus, GLUT gives window system leeway to support the menu functionality in another manner (pull-down menus for example).
GLUT is designed for simple to moderately complex programs focused on OpenGL rendering. GLUT implements its own event loop. For this reason, mixing GLUT with other APIs that demand their own event handling structure may be difficult. The advantage of a builtin event dispatch loop is simplicity.
GLUT routines are logically organized into several sub-APIs according to their functionality. The sub-APIs are:
- Initialization: Command line processing, window system initialization, and initial window creation state are controlled by these routines.
- Beginning Event Processing: This routine enters GLUT’s event processing loop. This routine never returns, and it continuously calls GLUT callbacks as necessary.
- Window Management: These routines create and control windows.
- Overlay Management: These routines establish and manage overlays for windows.
- Menu Management: These routines create and control pop-up menus.
- Callback Registration: These routines register callbacks to be called by the GLUT event processing loop.
- Color Index Colormap Management: These routines allow the manipulation of color index colormaps for windows.
- State Retrieval: These routines allows programs to retrieve state from GLUT.
- Font Rendering: These routines allow rendering of stroke and bitmap fonts.
- Geometric Shape Rendering: These routines allow the rendering of 3D geometric objects including spheres, cones, icosahedrons, and teapots.
The Author
{module [313]}