How OpenGL differs from the IrisGL
May, 1992


Kurt Akeley
May 1992
How OpenGL differs from the IrisGL

Each difference is given a simple name, followed by a description.

window management

	OpenGL 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 roughtly 10 commands for this purpose.

	IrisGL commands such as gconfig and drawmode are not implemented
	by OpenGL.

display list editing

	OpenGL display lists cannot be edited, only created and destroyed.
	Because display list names are specified by the programmer, however,
	it is possible to redefine individual display lists in a hierarchy.

	OpenGL display lists are designed for data caching, not for data
	base 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 Begin and End commands,
	so the display list hierarchy can be made fine enough that it can
	in effect be edited.

concave polygons

	The core OpenGL API does not handle concave polygons, but the
	utility library does provide support for decomposing concave,
	non self intersecting contours into triangles.  These triangles
	can either be draw immediately or returned.

polygon stipple

	In Iris GL the polygon stipple pattern was screen-relative.
	In OpenGL it is window relative.

polygon vertex count

	There is no limit to the number of vertexes between Begin and End
	in OpenGL, even for Begin(POLYGON).  In Iris GL polygons are
	limited to no more than 255 vertexes.

polygon mode

	OpenGL supports only filled, outlined, and dotted polygons.  There
	is no hollow polygon mode as in Iris GL.  OpenGL polygons modes
	are specified separately for front and back facing polygons, while
	Iris GL shares a single mode for all polygons.

pixel coordinates

	OpenGL and IrisGL agree that 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 IrisGL placed
	it at the center of the lower left pixel.

swaptmesh

	OpenGL does not support the swaptmesh capability.  It does offer
	two types of triangle meshes, however, one that corresponds to the
	default "strip" behavior of the IrisGL, and another that corresponds
	to calling swaptmesh prior to the third and all subsequent vertexes
	when using IrisGL.

current graphics position

	OpenGL does not maintain a current graphics position.  IrisGL
	commands that depended on current graphics position, such as
	relative lines and polygons, are not included in OpenGL.

color/normal flag

	OpenGL lighting is explicitly enabled or disabled.  When enabled,
	it is effective regardless of the order in which colors and normals
	are specified.

	Lighting cannot be enabled or disabled between OpenGL Begin() and
	End() commands.  If lighting must be disabled between Begin() and
	End(), it must be effected by specifying zero ambient, diffuse,
	and specular material reflectance, and material emmision of the
	desired color.

lighting equation

	The 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 as in Iris GL, and OpenGL regularizes the equation
	so that ambient, diffuse, and specular lighting contributions
	are all attenuated.  Also, OpenGL allows separate colors to be
	specified for the ambient, diffuse, and specular intensities
	of light sources, as well as for the ambient, diffuse, and
	specular reflectances of materials.  All OpenGL light and
	material colors include alpha.

	Setting the specular exponent to zero does NOT defeat specular
	lighting in OpenGL.

	OpenGL supports local lights in color index mode.  Iris GL
	does not.

ColorMaterial

	The OpenGL ColorMaterial command replaces the Iris GL lmcolor
	command, but is not exactly equivalent.  The OpenGL state model
	is simple - the specified material properties track the current
	color while ColorMaterial is enabled.  The Iris GL state model
	is complex and not very well defined.

hollow polygons

	OpenGL does not support hollow polygons.  The OpenGL stencil
	capability can be used by programmers to render hollow polygons,
	however.

single matrix mode

	OpenGL always maintains two matrixes: ModelView and Projection.
	While an OpenGL implementation may consolodate these into a
	single matrix for performance reasons, it must always present
	the 2-matrix model to the programmer.

non subpixel

	All OpenGL rendering is subpixel positioned.

current computed color

	OpenGL has no notion of a current computed color.  Programmers
	using OpenGL as a lighting engine must use feedback to obtain
	colors generated by lighting calculations.

packed color formats

	OpenGL 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 IrisGL accepted packed colors both for geometric and
	pixel rendering, OpenGL accepts arrays of color components for
	geometric and pixel rendering.

index clamping

	Where possible OpenGL treats color and stencil indexes as
	bitfields rather than numbers.  Thus indexes are masked,
	rather than clamped, to the supported range of the framebuffer.

closed lines

	OpenGL 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.

antialiased lines

	OpenGL stipples antialiased lines.  Iris GL does not.

automatic texture scaling

	The OpenGL texture interface does not support automatic scaling
	of images to power-of-two dimensions.  However, image scaling
	is supported by the OpenGL utility library.

automatic generation of mipmaps

	The OpenGL texture interface does not support automatic generation
	of mipmap images.  However, automatic generation of mipmap images
	is supported by the utility library for both 1D and 2D textures.

texture filtering

	OpenGL textures are filtered with a border when they are clamped.
	Iris GL does not use the border data in this case.

rgba logicop

	OpenGL does not support logical operations on RGBA buffers.

accumulation wrapping

	OpenGL accumulation buffer operation is not defined when
	component values exceed 1.0 or go below -1.0.

per-bit color writemask

	OpenGL 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 writemask

	OpenGL writemasks for depth components enable or disable changes
	to the entire component, not to individual bits of the depth
	component.

arc

	OpenGL supports arcs in its utility library.

circle

	OpenGL supports circles in its utility library.

bbox

	OpenGL does not support conditional execution of display lists.

nurbs

	OpenGL supports NURBS with a combination of core capability
	(evaluators) and utility library support.  All IrisGL NURBS
	capabilities are supported.

curves

	OpenGL does not support IrisGL curves.  Use of NURBS curves
	is recommended.

patches

	OpenGL does not support IrisGL patches.  Use of NURBS surfaces
	is recommended.

callfunc

	OpenGL does not support callback from display lists.  Note that
	IrisGL also did not support this functionality when client and
	server were on different platforms.

depthcue

	OpenGL provides no direct support for depth cueing.  However,
	its fog support is a more general capability that can easily
	be used to emulate IrisGL depthcue.

fog

	OpenGL fog equations are very similar to Iris GL equations,
	but they do not include the 5.5 scale factor that was built
	into the Iris GL equations.

move/draw/pmove/pdraw/pclos

	OpenGL 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.

relative move/draw/pmove/pdraw/pclos

	OpenGL does not maintain a current graphics position, and
	therefore is unable to support relative vertex operations.
	The semantics of such operations can easily be emulated by
	using the matrix and glTranslate(), however.

feedback format

	OpenGL specifies a set of feedback formats that allow programmers
	to specify how much data is returned.  While none of these formats
	matches any of the IrisGL formats, they collectively represent a
	superset of IrisGL capabilities.

pick

	The OpenGL utility library includes support for generating a
	pick matrix.

polygon provoking vertex

	Flat shaded IrisGL polygons took the color of the last vertex
	specified, while OpenGL polygons take the color of the first
	vertex specified.

scrbox

	OpenGL does not support bounding box computation.

def/binds

	OpenGL does not have the concept of a material, light, or texture
	objects, only of material, light, and texture properties.  OpenGL
	programmers can use display lists to create their own objects,
	however.  Implementors will be encouraged to optimize for display
	lists that contain only materials properties, light properties,
	textures properties, or a single bitmap.

mapw

	OpenGL utilities support mapping between object and window
	coordinates.

polf/poly

	OpenGL provides no direct support for vertex lists other than
	display lists.  Functions like polf and poly can easily be
	implemented using the OpenGL api, however.

attribute lists differ

	The attributes pushed by IrisGL pushattributes differ from any
	of the attribute sets that are pushed by OpenGL PushAttrib.
	Because all OpenGL state can be read back, however, it is
	possible to implement any desired push/pop semantics using the
	OpenGL api.

readdisplay

	Reading pixels outside window boundaries is properly a window
	system capability, rather than a renderer capability.  We will
	propose an extension to X to replace the IrisGL readdisplay
	command.

reset linestyle

	IrisGL resetls has not been supported for some time, and is not
	supported by OpenGL.

sbox

	sbox is an IrisGL rectangle primitive that is well defined only
	if transformed without rotation, and is designed to be faster than
	standard rectangles.  While OpenGL does not support such a
	primitive, it can (and will) be tuned to render rectangles very
	quickly when the matrixes and other modes are in states that
	simplify calculations.

scrsubdivide

	Screen subdivision is not supported by OpenGL.

fonts and strings

	OpenGL expects 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.  CallLists 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 IrisGL fonts,
	and considerably more.  For example, characters comprised of
	triangles can be as easily manipulated.

z rendering

	OpenGL does not 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 cannot share memory with the
	depth buffer in any single configuration.

pixmode

	OpenGL pixel transfers operate on individual color components,
	rather than on packed groups of 4 8-bit components as does IrisGL.
	While OpenGL provides substantially more pixel capability than
	IrisGL, it does not support packed color constructs, and it does
	not allow color components to be reassigned (red to green, red to
	blue, etc.) during pixel copy operations.

pixel zoom

	OpenGL 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.

old polygon mode

	Aliased OpenGL polygons are always point sampled.  The old polygon
	compatibility mode of the IrisGL, where pixels outside the polygon
	perimeter were included in its rasterization, is not supported.
	(Rendering antialiased polygons with blending disabled is a good
	approximation, however!)

clear options

	OpenGL really clears buffers.  It does not apply currently
	specified pixel operations such as blending and logicop, regardless
	of their modes.  Programmers who wish to clear using such features
	must render a window-size polygon.

matrix mode

	All OpenGL matrix operations operate on the current matrix,
	rather than on a particular matrix, as do the IrisGL ortho, ortho2,
	perspective, and window commands.  All OpenGL matrix operations
	except LoadIdentity and LoadMatrix multiply the current matrix
	rather than replacing it (as do ortho, ortho2, perspective, and
	window in the Iris GL).

frontbuffer

	IrisGL had complex rules for defeating rendering to the front
	buffer in singlebuffer mode.  OpenGL does as it is asked in this
	regard.

mprojection mode

	IrisGL did not 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.

window offset

	IrisGL returned viewport and character position in screen, rather
	than window, coordinates.  OpenGL always deals with window
	coordinates.

scalar arguments

	All OpenGL commands that are accepted between Begin and End have
	entry points that accept scalar arguments.  For example,
	Color4f(red,green,blue,alpha).

vector arguments

	All OpenGL commands that are accepted between Begin and End have
	entry points that accept vector arguments.  For example,
	Color4fv(v).

integer colors

	Signed integer color components (red, green, blue, or alpha)
	are linearly mapped to floating point such that the most negative
	integer maps to -1.0 and the most positive integer maps to 1.0.
	This mapping occurs when the color is specified, before it
	replaces the current color.

	Unsigned integer color components are linearly mapped to floating
	point such that 0 maps to 0.0 and the largest representable
	integer maps to 1.0.  This mapping occurs when the color is
	specified, before it replaces the current color.

integer normals

	Integer normal components are mapped just like signed color
	components, such that the most negative integer maps to -1.0,
	and the most positive integer maps to 1.0.

pixel fragments

	Pixels drawn by DrawPixels or CopyPixels are always rasterized
	and converted to fragments.  The resulting fragments are textured,
	fogged, depth buffered, blended, etc. just as if they had be
	generated from geometric points.  Fragment data that are not
	provided by the source pixels are 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.  All pixel fragments take their
	X and Y address as an offset from the raster position x,y values.

error side effects

	When 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.  (Exception is the OUT_OF_MEMORY error,
	which is fatal.)

error checking

	OpenGL checks for errors more carefully than Iris GL.  For example,
	all OpenGL commands that are not accepted between Begin and End
	are detected as errors, and have no other effect.

error return values

	When 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.

invariance

	OpenGL guarantees certain invariances that Iris GL does not.
	For example, OpenGL guarantees that identical code sequences
	sent to the same system, differing only in the blending
	function specified, will generate the same pixel fragments.
	(The fragments may be different if blending is enabled and
	disabled, however.)

multi-buffer drawing

	OpenGL 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 did.

scissor

	OpenGL scissor does not track the viewport, and is not constrained
	to be within the viewport.  The Iris GL viewport command
	automatically updates the scrmask, and the Iris GL scrmask must
	be within the bounds of the viewport.

normals

	OpenGL transforms normals using the exact inverse of the ModelView
	matrix.  Thus all scale commands, even scale command with the same
	scale values for x, y, and z, affect the lengths of transformed
	normals.  Avoid calling glScale() if you want the performance
	advantage of leaving GL_NORMALIZE disabled.

stencil

	When there is no depth buffer, or when the depth buffer is not
	enabled, StencilOp argument zpass controls stencil operation when
	the stencil test passes.  Iris GL stencil operation is defined by
	it "pass" parameter (equivalent to OpenGL zfail) in this case.

line stipple repeat

	OpenGL line stipple repeat is clamped to [1,256], while Iris GL
	clamps this value to [1,255].