![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to x.t CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSD / contrib / X / doc / Usenix|
Return to x.t CVS log | Up to [CSRG BSD Unix] / 43BSD / contrib / X / doc / Usenix |
1.1 root 1: .LP
2: .SH
3: X Window System Design
4: .PP
5: While this paper is not specifically about the X window system,
6: X will be used as an example for much of the discussion.
7: X is best described using a client/server model.
8: X consists of a collection of client programs which
9: communicate with the window system server.
10: They are implemented entirely in user code.
11: All communications with the window system occur over a stream
12: connection to the window system.
13: X is completely network transparent; i.e. a client program
14: can be running on any machine in a network, and the clients and
15: the server need not be executing on the same machine architecture.
16: The block diagram shown in Figure 1 describes the structure of the system.
17: .PP
18: X supports overlapping possibly transparent windows and
19: subwindows to arbitrary depth.
20: Client programs can create, destroy, move, resize, and restack windows.
21: X will inform clients on request of key presses,
22: key releases, button presses, button releases,
23: mouse window entry and exit, mouse motion,
24: a number of types of window exposure,
25: unmap (removal of a window from the screen),
26: and input focus change.
27: Cut and paste buffers are provided in the server as untyped bytes.
28: Graphic primitives provided include dashed and dotted
29: multi-width lines, and splines.
30: There is a full complement of raster operations available.
31: The implementation supports color,
32: though the current protocol limits the depth of a display to
33: 16 bits/pixel.
34: .PP
35: The X window system consists of a collection of
36: .UX
37: programs
38: providing various services on a bitmap display.
39: There is only a minimal device driver to field interrupts from
40: mouse, keyboard, and potentially a display engine.
41: The X server accepts connections from client applications programs.
42: Window, text and graphics commands are all multiplexed over (usually)
43: a single connection per client.
44: Multiple clients may connect to the server.
45: .PP
46: The X protocol is the only way to communicate to the window system.
47: The X server enforces clipping, does resource allocation,
48: multiplexes output from multiple clients, performs hit detection
49: for mouse and keyboard events, and performs graphics
50: primitives in windows.
51: The protocol is entirely based on a stream.
52: The current implementation uses TCP as its stream
53: transport layer; though it
54: has been run experimentally using DECNET stream connections.
55: A client program may run on any machine in a network.
56: On a local net, performance is the same or better when run remotely
57: as when run locally given two identical unloaded processors.
58: .PP
59: The X server is a single threaded server program.
60: Requests from clients are processed in a round robin fashion
61: to provide apparently simultaneous output.
62: This has proven to be sufficient,
63: and vastly simplified the design and implementation.
64: Single threading provides all locking and synchronization without any
65: complex structure.
66: The X server must therefore be very careful never to block waiting
67: on a client,
68: and exploits the observation that each individual graphics operation
69: is very
70: fast on a human time scale (though it may be slow on a systems time scale).
71: The 4.2BSD facilities that make this easy to implement
72: include select(2), non-blocking I/O, and the network mechanism
73: (IPC to unrelated processes).
74: .PP
75: The current X server implementation does NOT maintain the contents of windows.
76: Refresh of a damaged window is the responsibility of the client.
77: The server will inform a client if the contents of a window has been
78: damaged.
79: This was motivated by a number of observations:
80: 1) clients often have their own backing store, and this must be maintained
81: by most programs when resized anyway;
82: if the window system provides backing store, it is often duplicating
83: existing facilities.
84: 2) keep the window system simple and FAST.
85: 3) the amount of data that would have to be stored for bitmap backing
86: store on color displays is very large.
87: Naive
88: .UX
89: applications are run under a terminal emulator which provides
90: the refresh function for them.
91: .PP
92: X delegates as much to a client as possible.
93: It provides low level ``hooks'' for window management.
94: No less than three window manager programs (a separate client program in
95: the X design from the window system) have been written to date,
96: and provide quite different user interfaces.
97: Menus are left to client code to implement, using the
98: flexible primitives X provides.
99: There have been four different styles of menus implemented to
100: date, including a quite sophisticated ``deck of cards'' menu package.
101: .KS
102: .sp 20
103: .ce 1
104: Figure 1: Block Diagram Structure of X
105: .KE
106: .PP
107: X runs as of this writing on four quite different types of hardware,
108: from very intelligent to very simple.
109: An example of a very intelligent (and reasonably well designed) piece of
110: hardware from the programmers point of view is the DEC Vs100,
111: though it suffers due to the nature of its interface to a VAX,
112: which adds overhead and latencies to each operation.
113: A QVSS display on a MicroVAX (VS1 and VS2)
114: is at the opposite end of the spectrum,
115: being a simple bitmap with no hardware assist.
116: Other ports are in progress.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.