Why X is not our ideal window system

Why X Is Not Our Ideal Window System

Hania GajewskaMark S. Manasse

DEC Systems Research Center

130 Lytton Ave. Palo Alto, CA 94301

Joel McCormack

DEC Western Research Laboratory100 Hamilton Ave. Palo Alto, CA 94301

Abstract

Extensive experience with X11 has convinced us that it represents a true advance in windowsystems, but that there are areas in which the X protocol is seriously deficient. The problems wedescribe fall into seven categories: coordinate system pitfalls, unavoidable race conditions,incomplete support for window managers, insufficient window viewability information, difficultieswith interactive mouse-tracking, pop-up and redisplay inefficiencies, and exceptional conditionhandling. We propose solutions for most of these problems. Some solutions could be easilyincorporated into the X11 protocol. Other proposals are too incompatible to be adopted, but arenonetheless included for the benefit of future window system designers.

1. Introduction

We come to praise X, not to bury it. Our combined experience with X11 encompasses the

design and implementation of several window managers, the design and implementation of the

Xtk toolkit intrinsics, ports of the X server, and protocol converters between X and other

windowing systems.

This experience has convinced us that X represents an advance in window systems: it is

network-transparent, it runs on a wide variety of graphics hardware, and it provides an efficient

connection to the capabilities of the underlying hardware. The same experience has also

convinced us that X is not a perfect window system. In this paper we limit ourselves to specific

problems with the X11 protocol [7]; we do not complain about the philosophy or imaging model

underlying X, nor do we bemoan the fact that X is not NeWS [3], NeXTstep [9], PostScript [1], or

PHIGS [6].

The problems we have encountered fall into seven categories:

1.The mixing of signed and unsigned coordinates causes problems both in theprotocol, where 3/4 of the coordinate space is often unrepresentable, and in the Clanguage bindings.

2.The X protocol is asynchronous for efficiency: in general, neither the server norclients wait for replies. But the protocol’s synchronization mechanisms areinsufficient, and leave many unavoidable race conditions.

3.The X protocol attempts to be policy-free and tries not to dictate any particular styleof window management. However, some desirable window manager featurescannot be implemented correctly, because there are window attributes which thewindow manager can neither fetch nor monitor.4.The X protocol provides visibility notification events so that clients can avoidcomputation of obscured window contents. However, this notification doesn’t workwell for nested windows or for windows with backing store.

5.None of the several ways that an application can implement interactive mousetracking of crosshairs, bounding boxes, etc., allow both efficiency and correctness.

6.Popping up menus and dialog boxes is slow because it requires too many roundtrips and generates too many events. Repainting when portions of a windowbecome visible is often slow.

7.Exceptional conditions are poorly handled. Faulty programs can freeze the server,and clients cannot kill queued requests if the user doesn’t want to wait for theserver to finish servicing them.

Although we define some X-specific vocabulary, we recommend keeping handy a glossary of X

terms, such as the one in Reference [7], while reading this paper.

2. Coordinate Representation

There are three problems in X11’s definition of coordinates: positions and sizes have different

physical representations, window borders introduce inconsistent views of a window’s coordinate

system, and the restriction that window sizes must be positive leads to unnecessary special

cases.

2.1. Signed positions vs. unsigned dimensions

The X11 protocol defines x and y coordinates as 16-bitsignedintegers, and width and height

dimensions as 16-bitunsignedintegers. A window, or any other rectangle, is defined by the

signed position of its north-west corner and the unsigned dimensions of its width and height. This

makes sense intuitively: the coordinates of the north-west corner of a window may be beyond the

boundaries of its parent window and thus negative, while width and height are generally thought

of as nonnegative values.

However, using all 16 bits to create a very tall window is pointless, because many positions in

the window cannot be addressed using signed 16-bit values. For example:

•All text strings must begin in the top half of the window.

•All rectangles and subwindows must have their upper left corner in the top half of thewindow.