A little while ago, I wrote about the use of color-keyed overlays to render video smoothly. The idea is that the CPU itself produces an image with a block of solid color (green in my example), and the graphics card is instructed to replace those pixels with the pixels from an off-screen image that it generated separately. Rather than doing the image composition in the CPU, the composition happens in the video card as the image leaves the card and goes to the monitor.

In the subsequent discussion, some people remembered this technique but noted that in their recollection, the color-key was not green but some other color. What’s going on?

When you set up the color-keying with the video card, you gave it a few instructions. You told it where to find the off-screen replacement image and how big it was. You told it the size and location of the on-screen rectangle where the replacement image should go. And you told it the magic color to look for inside that rectangle.

So the CPU got to pick the color-key color.

Choosing a color-key color was a bit tricky. If another window overlapped your video playback window, and they used your color-key color, then your video would play “through” the other window at any place it used that color. Therefore, when choosing a color-key color, you wanted to pick a color that is not commonly encountered. You didn’t want white or black, for example, because those are all over the place. Common choices were either neon-bright colors such as bright green or bright magenta because they are so ugly that nobody would even use them on purpose, or very dark colors like #010000 because they are so close to black that most normal people would just pick black outright.

The neon-bright colors were also useful when debugging because it’s extremely noticeable when you messed up.

Video card support for overlays was extremely varied. Some cards didn’t support them. Others did, but with restrictions. For example, “Oh, I can do overlays, but no more than four at a time, and they cannot have overlapping destination rectangles, and furthermore, I cannot apply a scale factor smaller than 1.0 or larger than 1.3.” Navagating all of these limitations and restrictions was quite a cumbersome undertaking for programs that wanted to use the feature.

The key to all this overlay trickery is that the magic happened inside the video card, and the result went out to the monitor without ever being sent back to the CPU. Programs themselves never saw the result of the overlay. All that programs saw or knew about were the color-keyed pixels. When you took the screen shot, you got the green (or whatever) pixels. When you loaded the bitmap into Paint, it showed green pixels, (but if an overlay was active, the video card changed them to something else before sending them to the monitor). When Paint saved the bitmap, it just saved green pixels. As far as anybody on the computer could tell, those pixels were just boring green pixels.