This article does not cite any sources. (August 2014) (Learn how and when to remove this template message)
A display list (or display file) is a series of graphics commands that define an output image. The image is created (rendered) by executing the commands to combine various primitives. This activity is most often performed by specialized display or processing hardware partly or completely independent of the system's CPU for the purpose of freeing the CPU from the overhead of maintaining the display, and may provide output features or speed beyond the CPU's capability.
For a display device without a frame buffer, such as the old vector graphics displays, the commands were executed every fraction of a second to maintain and animate the output. In modern systems, the commands need only be executed when they have changed or in order to refresh the output (e.g., when restoring a minimized window).
A display list can represent both two- and three-dimensional scenes. Systems that make use of a display list to store the scene are called retained mode systems as opposed to immediate mode systems.
One of the earliest popular systems with true display list was the Atari 8-bit family. The display list (actually called so in Atari terminology) is a series of instructions for ANTIC, the video co-processor used in these machines. This program, stored in the computer's memory and executed by ANTIC in real time, can specify blank lines, any of six text modes and eight graphics modes, which sections of the screen can be horizontally or vertically fine scrolled, and trigger Display List Interrupts (called Raster interrupts or HBI on other systems).
The Amstrad PCW family contains a Display List function called the 'Roller RAM'. This is a 512-byte RAM area consisting of 256 16-bit vectors into RAM, one for each line of the 720 × 256 pixel display. Each vector identifies the location of 90 bytes of monochrome pixels that hold the line's 720 pixel states. The 90 bytes of 8 pixel states are actually spaced at 8-byte intervals, so there are 7 unused bytes between each byte of pixel data. This suits how the text-orientated PCW constructs a typical screen buffer in RAM, where the first character's 8 rows are stored in the first 8 bytes, the second character's rows in the next 8 bytes and so on. The Roller RAM was implemented to speed up display scrolling as it would have been unacceptably slow for its 3.4 MHz Z80 to move up the 23 KB display buffer 'by hand' i.e. in software. The Roller RAM starting entry used at the beginning of a screen refresh is controlled by a Z80-writable I/O register. Therefore, the screen can be scrolled simply by changing this I/O register.
Another system using a Display List-like feature in hardware is the Amiga, which, not coincidentally, was also designed by some of the same people who made the Atari 8-bits custom hardware. The Amiga display hardware was extremely sophisticated for its time and, once directed to produce a display mode, it would continue to do so automatically for every following scan line. The computer also included a dedicated co-processor, called "Copper", which ran a simple program or 'Copper List' intended for modifying hardware registers in sync with the display. The Copper List instructions could direct the Copper to wait for the display to reach a specific position on the screen, and then change the contents of hardware registers. In effect, it was a processor dedicated to servicing Raster interrupts. The Copper was used by Workbench to mix multiple display modes (multiple resolutions and color palettes on the monitor at the same time), and by numerous programs to create rainbow and gradient effects on the screen. It was also capable of sprite multiplexing, repositioning a number of hardware sprites available per scanline.
In more primitive systems, the results of a display list can be simulated, though at the cost of CPU-intensive writes to certain display-mode, color-control, or other visual effect registers in the video device, rather than a series of rendering commands executed by the device. Thus, one must create the displayed image using some other rendering process, either before or while the CPU-driven display generation executes. In many cases, the image is also modified or re-rendered between frames. The image is then displayed in various ways, depending on the exact way in which the CPU-driven display code is implemented.