Export (0) Print
Expand All

IRIS GL and OpenGL Differences

This appendix lists the differences between OpenGL and IRIS GL. A term for each difference is given, followed by a description.

accumulation wrappingThe OpenGL accumulation buffer operation is not defined when component values exceed 1.0 or drop below 1.0.
antialiased linesOpenGL stipples antialiased lines. IRIS GL does not.
arcOpenGL supports arcs in its utility library.
attribute listsThe attributes pushed by the IRIS GL pushattributes differ from any of the attribute sets pushed by the OpenGL glPushAttrib . Since all OpenGL states can be read back, however, you can implement any desired push/pop semantics using OpenGL.
automatic texture scalingThe OpenGL texture interface does not support automatic scaling of images to power-of-two dimensions. However, the GLU supports image scaling.
bboxOpenGL doesn't support conditional execution of display lists.
callfuncOpenGL doesn't support callback from display lists. Note that IRIS GL doesn't support this functionality either, when client and server are on different platforms.
circleOpenGL supports circles with the GLU. In OpenGL both circles and arcs (disks and partial disks) can have holes. In addition, you can change subdivision of the primitives in OpenGL, whose surface normals are available for lighting.
clear optionsOpenGL actually clears buffers. It doesn't apply currently specified pixel operations, such as blending and logicop, regardless of their modes. To clear using such features, you must render a window-size polygon.
closed linesOpenGL renders all single-width aliased lines such that abutting lines share no pixels. This means that the last pixel of an independent line is not drawn.
color/normal flagOpenGL lighting is explicitly enabled or disabled. When enabled, it is effective regardless of the order in which colors and normals are specified. You cannot enable or disable lighting between OpenGL glBegin and glEnd commands. To disable lighting between glBegin and glEnd, specify zero ambient, diffuse, and specular material reflectance, and then set the material emission to the desired color.
concave polygonsThe core OpenGL API doesn't handle concave polygons, but the GLU supports decomposing concave, non-self-intersecting contours into triangles. These triangles can either be drawn immediately or returned.
current computed colorOpenGL has no equivalent to a current computed color. If you're using OpenGL as a lighting engine, you can use feedback to obtain colors generated by lighting calculations.
current graphics positionOpenGL doesn't maintain a current graphics position. IRIS GL commands that depend on current graphics position, such as relative lines and polygons, are not included in OpenGL.
curvesOpenGL does not support IRIS GL curves. Use of NURBS curves is recommended.
defs/bindsOpenGL doesn't have the concept of material, light, or texture objects; only of material, light, and texture properties. You can use display lists to create their own objects, however.
depthcueOpenGL provides no direct support for depth cueing, but its fog support is a more general capability that you can easily use to emulate the IRIS GL depthcue function.
display list editingOpenGL display lists can't be editedonly created and destroyed. Because you can specify display list names, however, you can redefine individual display lists in a hierarchy. OpenGL display lists are designed for data caching, not for database management. They are guaranteed to be stored on the server in client/server environments, so they are not limited by network bandwidth during execution. OpenGL display lists can be called between glBegin and glEnd commands, so the display list hierarchy can be made fine enough that it can, in effect, be edited.
error checkingOpenGL checks for errors more carefully than IRIS GL. For example, all OpenGL functions that are not accepted between glBegin and glEnd are detected as errors, and have no other effect.
error return valuesWhen an OpenGL command that returns a value detects an error, it always returns zero. OpenGL commands that return data through passed pointers make no change to the array contents if an error is detected.
error side effectsWhen an OpenGL command results in an error, its only side effect is to update the error flag to the appropriate value. No other state changes are made. (An exception is the OUT_OF_MEMORY error, which is fatal.)
feedbackFeedback is standardized in OpenGL so it doesn't change from machine to machine.
fonts and stringsOpenGL requires character glyphs to be manipulated as individual display lists. It provides a display list calling function that accepts a list of display list names, each name represented as 1, 2, or 4 bytes. The glCallLists function adds a separately specified offset to each display list name before the call, allowing lists of display list names to be treated as strings. This mechanism provides all the functionality of IRIS GL fonts, and considerably more. For example, characters comprised of triangles can be easily manipulated.
frontbufferIRIS GL has complex rules for rendering to the front buffer in single buffer mode. OpenGL handles rendering to the front buffer in a straightforward way.
hollow polygonsYou can use the OpenGL stencil capacity to render hollow polygons. OpenGL doesn't support other means for creating hollow polygons.
index clampingWhere possible, OpenGL treats color and stencil indexes as bit fields rather than numbers. Thus indexes are masked, rather than clamped, to the supported range of the framebuffer.
integer colorsSigned integer color components (red, green, blue, or alpha) are mapped in linear fashion to floating points so that the most negative integer maps to 1.0 and the most positive integer maps to 1.0. This mapping occurs when you specify the color before OpenGL replaces the current color. Unsigned integer color components are mapped linearly to floating points so that 0 maps to 0.0 and the largest integer maps to 1.0. This mapping occurs when you specify the color before OpenGL replaces the current color.
integer normalsInteger normal components are mapped just like signed color components. The most negative integer maps to 1.0, and the most positive integer maps to 1.0. pixel fragments. Pixels drawn by glDrawPixels or glCopyPixels are always rasterized and converted to fragments. The resulting fragments are textured, fogged, depth buffered, blended, and so on, just as if they were generated from geometric points. Fragment data that isn't provided by the source pixels is augmented from the current raster position. For example, RGBA pixels take the raster position Z and texture coordinates. Depth pixels take the raster position color and texture coordinates.
invarianceOpenGL guarantees a certain consistency that IRIS GL doesn't. For example, OpenGL guarantees that identical code sequences sent to the same system, differing only in the specified blending function, will generate the same pixel fragments. (The fragments differ, however, if blending is enabled and then disabled.)
lighting equationThe OpenGL lighting equation differs slightly from the IRIS GL equation. OpenGL supports separate attenuation for each light source, rather than a single attenuation for all the light sources like IRIS GL. OpenGL adjusts the equation so that ambient, diffuse, and specular lighting contributions are all attenuated. Also, OpenGL allows you to specify separate colors for the ambient, diffuse, and specular intensities of light sources, as well as for the ambient, diffuse, and specular reflectance of materials. All OpenGL light and material colors include alpha. Setting the specular exponent to zero does not defeat specular lighting in OpenGL.
mapwOpenGL utilities support mapping between object and window coordinates.
matrix modeWhere the IRIS GL ortho, ortho2, perspective, and window functions operate on a particular matrix, all OpenGL matrix operations work on the current matrix. All OpenGL matrix operations except glLoadIdentity and glLoadMatrix multiply the current matrix rather than replacing it (as do ortho, ortho2, perspective, and window in the IRIS GL).
mipmaps, automatic generationThe OpenGL texture interface does not support automatic generation of mipmap images. However, the GLU supports the automatic generation of mipmap images for both 1-D and 2-D textures.
move/draw/pmove/pdraw/pclosOpenGL supports only Begin/End style graphics, because it does not maintain a current graphics position. The scalar parameter specification of the old move/draw commands is accepted by OpenGL for all vertex related commands, however.
mprojection modeIRIS GL doesn't transform geometry by the modelview matrix while in projection matrix mode. OpenGL always transforms by both the modelview and the projection matrix, regardless of matrix mode.
multi-buffer drawingOpenGL renders to each color buffer individually, rather than computing a single, new, color value based on the contents of one color buffer and writing it to all the enabled color buffers, as IRIS GL does.
NURBSOpenGL supports NURBS with a combination of core capability (evaluators) and GLU support. All IRIS GL NURBS capabilities are supported.
old polygon modeAliased OpenGL polygons are always point-sampled. IRIS GL's polygon compatibility mode, where pixels outside the polygon perimeter are included in its rasterization, is not supported. If your code uses this polygon mode, it is probably for rectangles. Old polygon mode rectangles appear one pixel wider and higher.
packed color formatsOpenGL accepts colors as 8-bit components, but these components are treated as an array of bytes rather than as bytes packed into larger words. By encouraging array indexing rather than shifting, OpenGL promotes endian-invariant programming. Just as IRIS GL accepts packed colors both for geometric and pixel rendering, OpenGL accepts arrays of color components for geometric and pixel rendering.
patchesOpenGL doesn't support IRIS GL patches.
per-bit color writemaskOpenGL writemasks for color components enable or disable changes to the entire component (red, green, blue, or alpha), not to individual bits of components. Note that per-bit writemasks are supported for both color indexes and stencil indexes, however.
per-bit depth writemaskOpenGL writemasks for depth components enable or disable changes to the entire component, not to individual bits of the depth component.
pickThe OpenGL Utility library includes support for generating a pick matrix.
pixel coordinatesIn both OpenGL and IRIS GL, the origin of a window's coordinate system is at its lower left corner. OpenGL places the origin at the lower left corner of this pixel, however, while IRIS GL places it at the center of the lower left pixel.
pixel zoomOpenGL negative zoom factors reflect about the current graphics position. IRIS GL doesn't define the operation of negative zoom factors, and instead provides RIGHT_TO_LEFT and TOP_TO_BOTTOM reflection pixmodes. These reflection modes reflect in place, rather than about the current raster position. OpenGL doesn't define reflection modes.
pixmodeOpenGL pixel transfers operate on individual color components, rather than on packed groups of four 8-bit components as does IRIS GL. While OpenGL provides substantially more pixel capability than IRIS GL, it doesn't support packed color constructs, and it doesn't enable color components to be reassigned (red to green, red to blue, and so on) during pixel copy operations.
polf/polyOpenGL provides no direct support for vertex lists other than display lists. Functions like polf and poly can be implemented easily using the OpenGL API, however.
polygon provoking vertexFlat shaded IRIS GL polygons take the color of the last vertex specified, while OpenGL polygons take the color of the first vertex specified.
polygon stippleWith IRIS GL the polygon stipple pattern is relative to the screen. With OpenGL it is relative to a window.
polygon vertex countThere is no limit to the number of vertices between glBegin and glEnd with OpenGL, even for glBegin(POLYGON ). With IRIS GL, polygons are limited to no more than 255 vertices.
readdisplayReading pixels outside window boundaries is properly a window system capability, rather than a rendering capability. Use Windows functions to replace the IRIS GL readdisplay command.
relative move/draw/pmove/pdraw/pclosOpenGL doesn't maintain a current graphics position, and therefore doesn't support relative vertex operations.
RGBA logicop()OpenGL does not support logical operations on RGBA buffers.
sbox()sbox is an IRIS GL rectangle primitive that is well-defined only if transformed without rotation. It is designed to be rendered faster than standard rectangles. While OpenGL doesn't support such a primitive, it can be tuned to render rectangles very quickly when the matrices and other modes are in states that simplify calculations.
scalar argumentsAll OpenGL commands that are accepted between glBegin and glEnd have entry points that accept scalar arguments. For example, glColor4f (red, green, blue, alpha ).
scissorThe OpenGL glScissor function doesn't track the viewport. The IRIS GL viewport command automatically updates the scrmask.
scrbox()OpenGL doesn't support bounding box computation.
scrsubdivide()OpenGL doesn't support screen subdivision.
single matrix modeOpenGL always maintains two matrices: ModelView and Projection. While an OpenGL implementation can consolidate these into a single matrix for performance reasons, it must always present the two-matrix model to the programmer.
subpixel modeAll OpenGL rendering is subpixel positionedsubpixel mode is always on.
swaptmesh()OpenGL doesn't support the swaptmesh capability. It does offer two types of triangle meshes, however: one that corresponds to the default "strip" behavior of the IRIS GL, and another that corresponds to calling swaptmesh prior to the third and all subsequent vertices when using IRIS GL.
vector argumentsAll OpenGL commands that are accepted between glBegin and glEnd have entry points that accept vector arguments. For example, glColor4fv .
window managementOpenGL includes no window system commands. It is always supported as an extension to a window or operating system that includes capability for device and window control. Each extension provides a system-specific mechanism for creating, destroying, and manipulating OpenGL rendering contexts. For example, the OpenGL extension to the X window system (GLX) includes roughly 10 commands for this purpose. IRIS GL commands such as gconfig and drawmode are not implemented by OpenGL.
window offsetIRIS GL returns viewport and character positions in screen, rather than window, coordinates. OpenGL always uses window coordinates.
z renderingOpenGL doesn't support rendering colors to the depth buffer. It does allow for additional color buffers, which can be implemented using the same memory that is used for depth buffers in other window configurations. But these additional color buffers cannot share memory with the depth buffer in any single configuration.

 

 

 

Send comments about this topic to Microsoft

Build date: 3/6/2012

Community Additions

ADD
Show:
© 2014 Microsoft