Graphics History and the Red Book

by Mike Gleicher on September 2, 2014

The topic of this post might seem to be “Why are you asking me to read Chapters from a book about a depricated API.” But really, its to give you a sense of the history of computer graphics and a sense of why many of the things we’ll do in class are the way that they are. So there is actually useful information here.

We will have readings from “the Red Book” – also known as the “OpenGL Programmers Guide.” I will ask you to read from old editions. Mainly because I don’t have the new one and it may have changed.

Many important parts of this book having changed since the first edition (almost all the ones we care about). So you can read the ancient edition online if you like. The library has scanned the chapters we need for class from the recent (7th) edition, and those are available as PDFs on the library page and course reader.

Why this old book?

The reason for having you read from this book is not because I want you to learn about a circa 1995 API – even though we are going to use it a little in class. It’s because the book has some nice tutorial components to it, and the original API represents a way of thinking about graphics that is useful – even if the API you are using doesn’t force you to think this way.

Some history

(note: this is a rational reconstruction based on my own experience)

In the very old days, drawing graphics was slow. The only way to draw graphics quickly was to get a super computer. The early special effects companies went bankrupt because they tried to buy Crays and things like that.

In the late 1970s and early 1980s, workstations started to be produced commercially.

In the late 1970s, a professor at Stanford (Jim Clark) had the idea to try to build specialized hardware to do graphics (relatively) fast and fit it into a workstation. The plan was based on the existence of special chips for performing certain mathematical operations (like a chip for doing 4×4 matrix multiplies). He and his students started a company to bring the machines to market. The company was called Silicon Graphics (SGI).

SGI was not the only company that tried to make “graphics workstations” in the 1980s and early 1990s. The regular workstation companies (DEC, Sun, HP, IBM) and some other specialized graphics workstation companies (Stellar, Ardent, Integraph) tried as well. None were as successful.

There were a number of reasons why SGI was so successful. Part of it was the technical issues in the graphics. Part of it is that they were well engineered systems (graphics wasn’t added as an after-thought). Part of it was good marketing.

But a big part of SGIs success was that they made graphics easier to use than their competitors did. The hardware was designed around a convenient way to think about graphics. And the software layer (API) was a thin and convenient way of getting at the hardware. It didn’t get bogged down trying to provide lots of features or be too fancy.

Most importantly, this API didn’t try to be a standard or cross-platform. It wasn’t designed by committee. It was a library for talking to SGI’s graphics hardware. Period.

This library was called GL.

SGI was really successful in the late 1980s and early-mid 1990s. They dominated the graphics hardware market. Most interesting graphics software ran on their hardware. It was the machine you wanted to have if you were doing graphics.

Then, in the late 1990s SGI rapidly declined and pretty much died in the early 2000s. To be more precise, the graphics part of the business died. They stayed alive for a while making other things like parallel supercomputers. There are a lot of reasons for SGIs decline, some technical, some about market forces (e.g. the rise of the PC industry). The biggest reason is a bunch of bad business decisions. But that’s a whole ‘nother story.

GL vs. OpenGL

Remember that GL was about SGI hardware. If you didn’t have an SGI computer, you were out of luck. (for a number of reasons, the existence of a better graphics library was only one of them).

In the mid- to late- 1990s, other companies realized that GL was a good way to program graphics, and wanted to let programmers work that way. So, a standards group was formed and they created OpenGL. OpenGL was designed so that it didn’t require SGIs hardware and operating system. But, it worked like GL, which was designed with SGI’s hardware in mind. Mostly this was a good thing (since the hardware was based on good ways to think about graphics). But some things were weird, because the hardware did things in a weird way (like lighting). And some features were really historical: they were designed to support what early 1990s SGI hardware did, and the best way to use that.

For a while, this was great. We had a convenient way to program graphics that worked across different platforms.

But then, graphics hardware evolved. Very quickly. OpenGL had to be extended to provide people with access to these new features.

But worse, while the old ways of programming graphics (i.e. what the SGI hardware did in 1990) was convenient for many things, and was the most efficient way to do stuff for circa 1990 computers, it was not at all how modern hardware worked. In fact, it was quite inefficient since it was based on assumptions about what is fast and slow that are very different than the are now (or even were in 2004).

So, in the late 2000s, early 2010s, the folks in charge of OpenGL decided to remove all of the old circa 1980s/1990s stuff designed for SGI hardware. They call this part of OpenGL “legacy” OpenGL.

Using the “modern” OpenGL has a lot of advantages. It maps nicely to circa 201X graphics hardware – ranging from high end workstations to cell phones. It gives very direct access to the hardware. It cuts away a lot of stuff that you wonder “why did they do it THAT way?” (for which the answer was an unsatisfying “because that’s how the hardware worked in 1989).

The downside is the “modern” OpenGL is designed to be efficient – not necessarily convenient for the programmer. You end up implementing a lot of the legacy stuff yourself.

The Red Book

OK, now back to the book portion of the story.

Back in the late 80s, there weren’t many graphics textbooks. And the ones that there were, didn’t explain how to think about things the way that the people who built the SGI hardware thought about it. And you needed to think about things the way they did, because if you did, you could use the hardware effectively.

So, in order to get people to use GL well, SGI made 2 books. One was the reference manual for the library. The other was more of a tutorial. It showed you how to do things, but also gave some sense of what was going on, what the hardware did with the things you told it, and gave examples of how to use the features. This was called the GL programmers guide.

In 1988, SGI came out with a new computer called the “Personal Iris.” it was a little bigger than a modern tower PC (it wasn’t the size of a small refrigerator, like their earlier machines). It was small enough to go into a (lucky) graduate students office – if their advisor could afford to buy them one.

I was one of those lucky graduate students.  (yes, I started graduate school in 1988).

Along with the workstation tower was a 20 inch color monitor (a rarity in those days), and a complete set of manuals. Including the GL Programmers Guide. Guess what book I learned stuff from.

Fast forward to 1999. I am teaching 559 for the first time. We have a text book. But I also chose the (then non-obvious) idea of using OpenGL for the programming assignments. So I recommend students buy the programmer’s guide (which is largely an update of the original GL programmers guide, just adapted to OpenGL) as a reference. But what I find is that the tutorial aspects of the book are better than the textbook we had at the time. Students were learning the concepts from this book (much the way I did) – and it was actually not such a great reference.

(that said, the textbooks have gotten better)

OpenGL and 559

So,  what does this mean to to you, the 559 student…

  1. I am going to recommend that you read some of the OpenGL red book (parts that have basically been the same since the early 1990s) because it will give you a nice way to think about some graphics concepts – even if you don’t use the API that supports them directly.
  2. For at least one of the programming projects, we are going to use the “legacy” features in OpenGL. Mainly because I want to re-use some old framework code and don’t want to update it. But also, because it will help you see why it’s a convenient way to think about graphics.
  3. For at least some of the assignments and projects, you will need to use some newer OpenGL features as they are the way to actually use some of the concepts we’re learning in class (like Shaders). So, having a reference for these features will be handy. The OpenGL Red Book is both a tutorial and reference for these things.

Previous post:

Next post: