QuickDraw - History

History

QuickDraw started life as LisaGraf, as part of the Apple Lisa development. For the Macintosh it was initially simplified, but then later extended. Originally, QuickDraw GrafPorts only supported a bit depth of 1, that is one bit per pixel, or black and white. This suited the built-in screen of the early Macintosh, with its fixed size of 512×342 pixels. Limited color was supported using a crude planar model, allowing QuickDraw to drive some types of dot-matrix printer that used multi-colored ribbons, but very few applications supported this feature.

In 1987, the Macintosh II was developed and launched, which was designed as a more conventional three-box design - CPU, monitor and keyboard all separate. Because the monitor was separate, and larger than the original Mac, the video architecture had to necessarily change. In addition, the Mac II took the Macintosh from black-and-white to full color. Apple also decided at this time to support a seamless desktop spanning multiple monitors, an industry first. Thus Color QuickDraw, a significant extension of the original QuickDraw, was created. The original architecture lacked much provision for expandability, but using a series of hacks, the Apple developers managed to make the addition of color and the new video architecture virtually seamless to both developers and end users.

Color QuickDraw introduced new data structures, including GDevices to represent each attached video card/monitor, and a new color GrafPort (CGrafPort) structure to handle color, as well as PixMaps instead of BitMaps for multiple bits-per-pixel images. One of the hacks for compatibility used here was that the new structure was exactly the same size as the old one, with most data members in the same place, but with additional handles and pointers to color structures in place of the BitMap fields. The upper two bits of the rowBytes field were pressed into use as flags to distinguish a GrafPort from a CGrafPort (they were always zero on old-style GrafPorts because a BitMap could never feasibly be so wide as to ever set these bits). The use of these two high bits would come back to haunt QuickDraw later, as it forced a maximum row width of just 4,096 on 32-bit PixMaps, which became problematic for high-resolution graphics work. Later development (Carbon) eliminated this limitation but was not fully backward compatible. A Palette Manager was also added in Color QuickDraw which managed the arbitration of colors on indexed video devices. Most graphics primitives operations remained either unchanged (but would operate in color), or else new color versions of the black and white APIs were added.

Initially, Color QuickDraw was only capable of operating with 1, 2, 4 and 8-bit video cards, which were all that was available at the time. Soon after however, 24-bit video cards appeared (so-called true color), and QuickDraw was updated again to support up to 32 bits per pixel (in reality, 24 bits, with 8 unused) of color data ("32-Bit QuickDraw"). The architecture always allowed for this, however, so no new APIs were necessary. The color data structures themselves allowed a color depth of 1, 2, 4, 8, 15 and 24 bits, yielding 1, 4, 16, 256, 32,768 and 16,777,216 colors respectively, or 4, 16 and 256 scales of grey. QuickDraw took care of managing the resampling of colors to the available color depths of the actual video hardware, or transfer between offscreen image buffers, including optionally dithering images down to a lower depth to improve image quality. A set of color sampling utilities were also added so that programmers could generate optimal color palettes for use with indexed video devices.

The architecture of QuickDraw had always allowed the creation of GrafPorts and their associated BitMaps or PixMaps "offscreen", where graphics could be composed in memory without it being visible immediately on the screen. Pixels could be transferred between these offscreen ports and the screen using the QuickDraw blitting function CopyBits. Such offscreen compositing is the workhorse for games and graphics-intensive applications. However, until the advent of 32-Bit QuickDraw, such offscreen worlds had to be created and set up by hand by the programmer within his application, and involving as it did three or more separate and fairly complex data structures (CGrafPort, PixMap and GDevice, and for indexed devices, the color look-up table and its inverse), could be error prone. With 32-Bit QuickDraw, OS support for handling this was added, with the "Offscreen Graphics World" or GWorld. The video buffer (PixMap) of a GWorld could be stored in main memory, or when available in unused parts of video ram where copying to the screen could be optimized for speed by avoiding the need to transfer a large amount of pixel data across the main memory bus.

With the advent of QuickTime, QuickDraw gained the ability to deal with compressed raster data, such as JPEG. The QuickTime Image Compression Manager integrated closely with QuickDraw: in particular, image decompression calls were full-fledged QuickDraw drawing calls, and if a picture was being recorded, the compressed data would be saved as part of the picture, for display when the picture was later drawn. The Image Compression Manager also added integration with ColorSync color matching.

After this, apart from back-end changes to optimize for new processor architectures (PowerPC), QuickDraw remained largely unchanged throughout the rest of the life of the classic Mac OS. QuickDraw GX and QuickDraw 3D shared the QuickDraw name and were able to interoperate with QuickDraw PixMap and picture data structures, but were otherwise completely separate in functionality.

With Mac OS X, QuickDraw became part of the Carbon API. With the release of Mac OS X 10.4, QuickDraw was officially deprecated.