A display list is a series of graphics commands that define an output image. The image is created 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. 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 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. 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, and by numerous programs to create rainbow and gradient effects on the screen. The Amiga Copper was also capable of reconfiguring the sprite engine mid-frame, with only one scanline of delay. This allowed the Amiga to draw more than its 8 hardware sprites, so long as the additional sprites did not share scanlines with more than 7 other sprites. i.e., so long as at least one sprite had finished drawing, another sprite could be added below it on the screen. Additionally, the later 32-bit AGA chipset allowed drawing bigger sprites whilst retaining the same multiplexing. Note that the Amiga also had dedicated block-shifter hardware, which could draw larger objects into a framebuffer. This was often used in place of, or in addition to, sprites. 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. Examples of the results possible on these older machines requiring CPU-driven video include effects such as Commodore 64/128's mode, or Rainbow Processing on the ZX Spectrum.
Deprecation
Display lists have largely been deprecated in modern graphics architectures, as they represent a set of commands in the fixed function Graphics pipeline. Modern architectures use shaders and vertex buffer objects, to avoid tying graphics performance to the CPU. However, low level graphics APIs such as Vulkan and DirectX 12 do expose display list like functionality in the form of command buffers and command lists.
