Preparing for class

You might be wondering what is it that I do anyway? A little insight into my job. Besides research (eye tracking, a topic for another post some other time), my "bread and butter" occupation is teaching computer science. As I was thinking about my classes tomorrow, I thought I'd post my basic preparation process. This semester I'm teaching computer graphics in one class and eye tracking (coincidentally enough :) in another. I'll concentrate on the former here.

Computer graphics has changed somewhat since the time when I took the class myself (it would have been ca. 1990). Btw, at SIGGRAPH I met my undergrad computer graphics instructor; I see him almost every year when I attend. It's kinda cool to meet up with him — his research was and continues to be computer graphics, he works for Sony pictures now still doing pretty innovative things in graphics, I'm sure. I basically teach the same course material that I learned from him almost 20 years ago, but of course I update it to modern standards. And these standards (literally) are what have evolved over the years. The main one related to graphics programming is OpenGL. Back when I was learning graphics GL was not yet open, it was a proprietary C library offered by SGI. I remember we were programming on then-new Silicon Graphics Personal Iris 4D machines. Ironically, today's choice for graphics platforms are graphics cards, the most popular coming from NVidia and ATI. The irony lies in that these cards are in a sense the old SGI machines on a chip, miniaturized into what's called the Graphics Processing Unit, or GPU. Why is that ironic? Because the companies selling these cards are not called SGI!

But I digress...OpenGL is a graphics library (code) and as such comes with an API, or Application Program Interface. My job is to teach students how to use the API to render graphics objects on the screen. Besides OpenGL, a graphics program has to be able to open a window on the screen which is connected to the graphics card (via what is known as a graphics context). OpenGL does not do this on its own, rather, it leaves this choice up to the programmer. There are various ways to open up a graphics window. My toolkit of choice is Trolltech's Qt. This is a C++ Graphical User Interface or GUI (pronounced "gooey") API. And this is another major change from the way I learned graphics. Back when I learned it, there really was no GUI toolkit. Well, maybe there was, motif may have been around, but we ended up coding our own buttons, sliders, menus, etc. (I know, I know, at this point I could add that back when I went to school, we walked barefoot in the snow, uphill both ways, but I think I'll refrain :) The Qt toolkit is much nicer. Of course you have to know C++ to use it, but once you get the basic idea, it's not too hard to learn.

So what do I need to do tomorrow? Go over the program shown in the first image. This is the guts of the Qt program to draw an image on the screen. As you can see it's quite simple. After an image is read in (a file dialog or browser is provided by Qt, as are the file parsing routines), it gets displayed on the screen (two calls to OpenGL). The pixels just get transferred from the file (on disk) to the CPU (memory), then to the GPU.

So? Well, the above example is as easy an intro as I can come up with. But it's also a nice segue into two more extensions: using a texture map to draw the image and then using GLSL, the GL Shading Language. GLSL is really the next evolution of OpenGL. This is a language that lets the programmer program the GPU directly. This means that you now have the freedom to do some pretty interesting things with your graphics card. In fact, a whole new research area known as General-Purpose computing on GPUs, or GPGPU, has sprung up exploiting the GPU for its massively parallel processing capability. At SIGGRAPH, NVidia was advertising the "personal supercomputer" which is basically what the GPU is.

There you have it, tomorrow's lecture in a nutshell.