very large impact on performance. The graphics adapter will also have its own graphics memory systems similar to the complete com- puter (or a portion of the main memory designated as the graphics memory). In addition, the graphics adapter will have various programs running on it to create, process, and transmit the image to the monitor. The amount of this programming can vary widely depending on the coprocessor and memory.
The basic operation of the graphics adapter is pretty simple. As mentioned above, there is a graphics memory set aside by the design of the computer system (the graphics memory is a set of memory chips of the appropriate size and speed). First, the main computer program (such as the CAD software) determines what image is needed on the screen. Second, data is created for that image in the
34 Chapter 2
graphics memory. Third, the graphics adapter takes what has been put into the graphics memory and translates it into an image on the screen as quickly as pos- sible. The graphics adapter is constantly scanning the data in the graphics mem- ory and then creating the signal to scan down the monitor as it refreshing. Since there is a sort of “shuttling” of the data between the computer system and the monitor, and often there is electronic circuitry to temporarily hold or “buffer” the data as it is being shuttled, the terminology of “graphics buffer” or “picture buffer” or even “frame buffer” is often used to refer to the kind of data held by the graphics memory and various memory chips on the graphics adapter itself. The details of these processes is beyond the scope of this work, but the key concept is that there is a special graphics memory area and the graphics adapter is constantly trying to get the data that is symbolized in that memory sent to the monitor. Figure 2.6 shows a simple schematic.
The most misleading statement in the previous paragraph is the second step of the process—creating the data that is put into the graphics memory. In some cases, the CAD software will actually use the main CPU to figure out how to translate the concept of an analog geometric entity (such as a circle) into a set of digital data that can reside in the graphics memory. Obviously, the monitor with a limited number of pixels can not show a perfect circle; it needs to be broken down into a set of pixels that approximates the circle. If the CAD software itself creates this approximation and then sends the data to the graphics memory, then the graphics adapter does not perform this second step, and only has to do the third step (send the image data to the monitor).
However, in other cases, the CAD software will not determine the approxi- mation of the geometry and send the data to the graphics memory. In this case, the CAD software “calls on” the power of the graphics adapter (which would probably have a coprocessor in this case) to make the approximation and create the data in the graphics memory. In this situation, the graphics adapter is doing 2 jobs—creating the data in the graphics memory and sending the image to the monitor. Obviously, this will only work if the programming running on the graphics adapter is compatible with the way the CAD software needs the data to be created. The compatibility issues raised by graphics adapters are generally ad- dressed by the use of industry standards: agreements between computer and electronic device manufacturers to have components behave in certain, predeter- mined fashions based on some sort of language or protocol. The standards may arise from industry groups such as the IEEE or EIA. Or, they may be considered de facto standards which means that one manufacturer’s design is so pervasive, all other manufacturer’s change to match it accordingly. A very early example of a de facto standard for graphics was TCS or PLOT10 for Tektronix® 4014 termi- nals. A more recent standard would be OpenGL®.
At first, the task of creating digital approximation