A sidebar to the “Apple’s Lisa: A personal Office System” report published in January 1983, pp. 6.

This will be the year of the bit-map display. A flood of entries featuring bit-map display technology will make the conventional “character-mapped” displays to which we all have become accustomed as the standard for computer display devices seem passé. The appeal of a bit-map display is immediately apparent: It can display a complex graphic image, limited only by the resolution of the raster-scan CRT presenting the display. This is in contrast to the traditional character display which can only display a repertoire of characters (usually burned into a PROM), positioning the characters into a fixed grids (often 80×24 character positions). These character displays are sometimes (as in TRS-80 and Apple II microcomputers) used for “character graphics,” where each character position rectangle is further broken down into sub-character rectangles (often, six per character position) to provide somewhat better resolution. The rectangles thus created are still several scan lines high and several dot positions wide.

A bit-map display carries this sub-division process to the extreme: The computer can turn “on” or “off” each screen “pixel” or dot, and thus “high-resolution” graphics display becomes possible. Bit-map displays require at least one bit of RAM for every pixel on the screen (more for gray levels or color).

Of course, there are tradeoffs involved in adopting a bitmap display instead of a character-oriented one. Much at-tention has focused on the cost of the display memory, which has been a significant factor until recently. Now, though, the advent of the low-cost 64K-bit chip has permitted the use of bit-maps in even modestly-priced equipment, and attention has turned to another disadvantage of bitmap displays: the difficulty of maintaining fast response times.

Certain types of operations can be very slow on bit-mapped displays because of the necessity of doing what might be called “display processing.” For example, if a character is to be displayed, the small rectangular bit-map corresponding to that character has to be moved from a “font memory” into the proper screen location. This usually requires a program (albeit a very simple one) which does the data moving. (This process can be speeded up with special hardware, but then the cost is increased significantly.) The corresponding problem does not exist in conventional character-oriented terminals, where the character-generator ROM handles the conversion from ASCII characters in memory to dots on the display. This happens during the display-refresh process, so any change in display memory is instantly reflected on the screen display, without any CPU involvement.

The display-handling approach adopted by Lisa is well-suited to give rapid response to common operations without resorting to sophisticated (and expensive) display-handling hardware. Several things are done to simplify the problem. For example, when you use the mouse to move an icon or a window, you move only an outline that is the same size as the item being repositioned. Then, when the outline is in the proper spot and you release the button on the mouse, the contents of the window or icon is recreated in the new position. It is relatively easy and inexpensive to generate a freely-movable rectangle on the screen. To move freely the actual window, complete with contents, would require a more expensive solution. Lisa also avoids some potential response-time bottlenecks in the character-handling area by offering only a few styles and sizes.

But there are some unavoidable situations where Lisa’s response times are limited by display-processing delays. These are most evident in LisaWrite. The display processing software cannot keep up with the burst typing rate of a good typist – which is why the screen display sometimes lags behind what has been typed. A worse condition arises when you want to scroll all of the text in a window horizontally or vertically. To accomplish this Lisa must recalulate the entire bit-mapped display for the text window. This is why scrolling is so slow. In general, with a display such as Lisa’s it is better to move a screenful or so of data at a time rather than trying to scroll in small increments. LisaWrite supports such larger movements for vertical scrolling within a file, but not for horizontal scrolling.