There are many powerful tools for controlling the complexity of software, but each tool carries a performance price. Nevertheless, the designers of the X windows system managed to make extensive use of tools such as hierarchy, abstraction, layering, and modularity, without causing unacceptably low performance. The designers of X achieved this very desirable result by using their tools selectively with an eye towards performance.
The hierarchical windows in X are a powerful tool both for controlling complexity and for reducing code size. Windows in X are cheap: the X server can handle hundreds of windows at once (p91). Applications can be kept simple and small by reusing these cheap, hierarchical windows to implement buttons, menu items, and other widgets. More ambitious applications can get the functionality of having their own window system without having to reimplement it internally (p83). Smaller, less redundant code takes up less space, so the machine swaps less and therefore runs faster.
The designers of X knew that they had to choose abstractions that could have fast implementations. The connection between X client and X server is a good example of a well-chosen abstraction. This connection is an abstract data stream, which may be either ordinary inter-process communication or a network connection. The designers knew that network connections can be slow, and checked that the speed penalty was not too high. Scheifler and Gettys concluded that the performance of X ``is limited by display hardware rather than network communication'' (p80). The asynchronous form of the client-server connection was also chosen for performance reasons. The data transfer rates attainable with synchronous communication were not acceptable, so asynchronous communication was used (p87).
X's base window system and window manager provide an example of effective use of layers. The base window system hides the specific hardware and supports a variety of fast, device-independent mid-level primitives: line and curve drawing, bitmapped fonts, masking, region copying, etc. (pp92-95). Some graphics architectures do not allow access to fast low-level pixel pushing, so such operations are not exported by the base window system (pp92-93). The base window system also doesn't support high-level objects like scrollbars and pop-up menus, because different users have different needs. High-level objects are implemented in a separate layer, the X window managers, which can vary from user to user (pp83-84). Thus no user need be burdened by the cost of unwanted functionality. The base window system provides device-independent fast primitives, and the window manager provides user-specific functionality. X isolates hardware complexity and still achieves good speed by putting a layer in just the right place.
Modularity is heavily used throughout X. The entire client-server structure of X is modular, and the X server itself is implemented as a user-space module, separate from the kernel (p85). However, the designers of X occasionally violated modularity in order to achieve better performance. Ideally, the window manager would handle obscured region of overlapping windows by itself. The X designers considered two approaches to server-managed overlapping: display lists, which had response time problems, and offscreen images, which used too much memory (pp95-96). For performance reasons, X clients know when their own windows are exposed, and are responsible for redrawing them (p95). X uses further special interactions between clients and the server to speed up the use of pop-up menus (p98). Unfortunately, these complex interactions are needed to achieve good performance.
The X window system is a good illustration of the balanced use of techniques for controlling complexity. Tools should by used extensively, but they should be selected with performance in mind. In general, there is a right tool which will provide good control and good enough speed. In a few exceptional cases, performance needs may force high complexity.