Adaptive buffering of computer graphics vertex commands

Details Adaptive buffering of computer graphics vertex commands Adaptive buffering of computer graphics vertex commands

1999-04-03

2002-01-08

Chauhan, Ulka J. (Department: 2671)

Computer graphics processing and selective visual display system

Computer graphic processing system

Graphic command processing

C345S503000, C345S536000, C345S558000, C345S419000

Reexamination Certificate

active

06337689

ABSTRACT:

FIELD OF THE INVENTION
This invention relates to the field of computer graphics, and more particularly to a technique for speeding rendering performance by adaptively buffering vertex commands issued by application software.
BACKGROUND
Computer Graphics Systems and APIs
Modem graphics-intensive application software is usually written to assume the presence of a state machine in the host computer or network for generating graphical objects on a display. Such application software drives the display by first issuing state-setting commands for configuring the graphics state machine, and then issuing vertex commands that cause the state machine to render geometric primitives in accordance with the machine's current state. A graphics API, or “application programmer's interface,” is a set of defined commands that the application programmer may use to accomplish these activities in a device-independent manner. In short, a graphics API is a software interface to graphics hardware. One well-known graphics API is called “OpenGL.” OpenGL consists of about 150 defined commands that application programs may use to specify the objects and operations necessary to produce graphical images in a display window.
FIG. 1
illustrates a computer system
100
that utilizes OpenGL in a typical manner. Computer system
100
includes at least one CPU
102
, system memory
104
, memory and I/O controller
106
, and I/O devices
108
such as a printer, scanner, network interface or the like. A keyboard and mouse would also usually be present as I/O devices, of course, but may have their own types of interfaces to computer system
100
. Stored within system memory
104
are application software
130
and OpenGL software
132
. OpenGL software
132
includes OpenGL dispatch table
134
, device-independent OpenGL library
136
and device-dependent module
138
. Typically, memory and I/O controller
106
will include a system bus
110
and at least one bus interface such as AGP bus bridge
112
and PCI bus bridge
114
. PCI bus bridge
114
may be used to interface I/O devices
108
to system bus
110
, while AGP bus bridge
112
may be used, for example, to interface graphics subsystem
116
to system bus
110
. The specific types of buses shown in the drawing, as well as the overall architecture of computer system
100
, are provided by way of example only. Other bus types and architectures may be used in alternative OpenGL implementations. For example, it is well known to utilize OpenGL in an X Window System client-server environment in which the application program runs on one computer while its display appears on a remote computer.
Graphics subsystem
116
will typically include graphics rendering hardware
118
, frame buffer controller
120
and frame buffer memory
122
. Frame buffer controller
120
is interfaced with a video controller
124
(e.g., digital-to-analog converters and sync/blank generation circuitry) for driving display monitor
126
. Graphics rendering hardware
118
will typically include 2D acceleration and rasterization hardware interfaced with AGP bus
113
and frame buffer controller
120
. In higher-end embodiments, rendering hardware
118
may include 3D geometry acceleration hardware, as well as texture mapping hardware interfaced with a texture memory
128
.
In operation, application software
130
first utilizes operating system calls or windowing system calls to establish a window on the display. Thereafter, application software
130
may use OpenGL function calls to clear the established window and to draw geometric primitives such as points, lines and polygons into the window. The mechanics of those function calls will be better understood with reference to FIG.
2
: Device-independent OpenGL library
136
is typically implemented as a dynamically linkable library of code segments
200
-
204
wherein each code segment is for executing a corresponding OpenGL command. One entry exists in dispatch table
134
for each implemented OpenGL command; and each entry in the table is a pointer to the proper code segment
200
-
204
for executing the command. Thus, when application software
130
makes an OpenGL function call
206
, the name of the function called is used as an index into dispatch table
134
. The code segment
200
-
204
pointed to by the indexed entry is executed. Then control returns to application software
130
as shown at
208
.
Graphics Command Types
Application software
130
specifies geometric primitives to be drawn by their vertices. For example, to draw a triangle, application software
130
could make the following OpenGL function calls:
glBegin(GL_TRIANGLES);
glColor3f(1.0, 0.0, 0.0); /*red*/
glVertex2i(25, 25);
glColor3f(0.0, 1.0, 0.0); /*green*/
glVertex2i(100, 325);
glColor3f(0.0, 0.0, 1.0); /*blue*/
glVertex2i(175, 25);
glEnd( );
This series of functions calls would cause a triangle to be drawn having a red vertex at x,y coordinates (25, 25), a green vertex at coordinates (100, 325) and a blue vertex at coordinates (175, 25).
Each function call in the above example corresponds to a command. The glBegin and glEnd commands are delimiters used to indicate the beginning and the end of a geometric primitive. The glBegin command also specifies which primitive type (in this case, GL_TRIANGLES) the graphics pipeline should assume when rendering the vertices that follow the command. The glBegin and glEnd commands are instances of a class of OpenGL commands called “state” commands, so named because they cause the graphics pipeline or state machine to assume a certain state. Other examples of state commands would be commands that specify the locations or characteristics of light sources, commands that indicate clipping parameters, and so on. Changes to any of these latter kinds of states are called “modal” state changes, because they alter the mode of the graphics state machine.
The other class of OpenGL commands of interest herein is called “vertex commands.” There are two basic types of vertex commands: vertex attribute commands, and vertex coordinate commands. In the above example, the glColor commands are vertex attribute commands, because they specify the color attribute for a vertex. Other examples of vertex attribute commands would be glNormal, glTexCoord, glEdgeFlag and glMaterial. The glVertex commands in the above example are vertex coordinate commands, because they specify coordinates for a vertex. By way of further background, the glVertex 2 command specifies a vertex coordinate in two dimensions; but other vertex commands are available for specifying vertex coordinates in more than two dimensions—glVertex3, and glVertex4.
In the above example, two function calls were required for each vertex (in addition to the glBegin and glEnd function calls on either end of the sequence). For cases in which application software wishes to specify other attributes for each vertex, such as texture coordinates, normal direction, material type and edge flags, the application software must use an additional function call per vertex for each attribute. The number of function calls required to draw the primitive increases commensurately.
Array Functions
In order to reduce the number of OpenGL function calls required to specify the vertices of a given primitive, array functions were introduced with OpenGL version 1.1. When using array functions, application software
130
creates a separate array for each vertex attribute to be specified, and then draws the primitive by indexing into the arrays. For example, application software
130
can use the glArrayElement( ) function to draw a triangle by referencing individual array elements to specify the vertices:
static GLint vertices[ ] = {
  25,
  25,
 100,
 325,
 175,
  25
};
static GLfloat colors[ ] = {
 1.0,
 0.0,
0.0,
 0.0,
 1.0,
0.0,
 0.0,
 0.0,
1.0
};
glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_COLOR_ARRAY);
glColorPointer(3, GL_FLOAT, 0, co

Affiliated with

Also associated with

Rating

Adaptive buffering of computer graphics vertex commands does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Adaptive buffering of computer graphics vertex commands, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Adaptive buffering of computer graphics vertex commands will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2839813