USENIX Association Proceedings of the FREENIX Track: 2002 USENIX Annual Technical Conference Monterey, California, USA June 10-15, 2002 THE ADVANCED COMPUTING SYSTEMS ASSOCIATION © 2002 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. The Future is Coming: Where the X Window System Should Go Jim Gettys Cambridge Research Laboratory, Compaq Computer Corporation. [email protected] Abstract architectures. Changes to the X infrastructure in recent work make this retrofit into modern toolkits appear fea- sible, enabling a much more dynamic view of applica- tions. Also, applications must be able to adapt between The X Window System was developed as a desktop win- very different resolution displays (more than an order of dow system, in a large (for its time) campus scale net- magnitude) and differing pointing devices. work environment. In the last few years, it has escaped the desktop and appeared in laptop, handheld and other I cover the changes and infrastructure required to realize mobile network devices. X from its inception has been this vision, and hope to demonstrate a compelling part of a network transparent window system, and should thrive this vision in action. This vision provides a much more in this environment. Mobility forces a set of issues to compelling vision of what it means for applications to surface that were only partially foreseen in X’s design. work in your network. With the advent of high speed For one reason or other, the hopes for the design were metropolitan and wide area networks, and PDA’s with not entirely realized. high speed wireless networks, this vision will provide a key element of the coming pervasive computing system. Our original view of X’s use included highly mobile individuals (students moving between classes), and a hope, never generally realized for X, was the migration of applications between X servers. Toolkit implementers 1 Introduction typically did not understand and share this poorly enun- ciated vision and were primarily driven by pressing im- mediate needs, and X’s design and implementation made The X Window System [SG92] architecture lay fal- migration or replication difficult to implement as an af- low for at least five years, roughly the period from terthought. As a result, migration (and replication) was 1995 to 2000, though many of the extensions defined seldom implemented, and early toolkits such as Xt made after the base X11 architecture were questionable at it very difficult. Emacs is about the only widespread ap- best [Get00]. The good news is that the original X ar- plication capable of both migration and replication, and chitecture enabled the development of desktop systems it avoided using any toolkit. such as Gnome [dI99] and KDE [Dal99]. But to again match and then exceed other systems such as Microsoft You should be able to travel between work and home or Windows and Apple’s Aqua [App] in all areas, serious between systems running X at work and retrieve your further work is necessary. This paper attempts to out- running applications (with suitable authentication and line areas where base window system work is required authorization). You should be able to log out and “park” to again make X competitive with other current com- your applications somewhere until you retrieve them mercial systems, specifically in the current large scale later, either on the same display, or somewhere else. network environment. You should be able to migrate your application’s display from a handheld to a wall projector (for example, your I believe that migration and replication of running X ap- presentation), and back again. Applications should be plications is key to the near term future environment. A able to easily survive the loss of the X server (most com- number of issues made replication and/or migration dif- monly caused by the loss of the underlying TCP connec- ficult. These include (and some of which are discussed tion, when running remotely). in detail in [GP01]): There are challenges not fully foreseen: applications must be able to adapt between highly variable display Fonts have been server side objects, and there is no guarantee the fonts available on one server are The X extension mechanism is at best only a partial so- available on the other (slightly mitigated by the ex- lution, since if an application relies on an extension’s istence of font servers). existence, it cannot be deployed until the X server has been upgraded. Many older systems can never be up- Graphics operations in X can be made to drawables dated with new X extensions. Application developers (windows or off screen memory, called “pixmaps”). won’t use a new feature if it badly restricts the market The X protocol only guarantees 1 bit deep draw- for their software. ables. Displays of different depths might share no other depth. Futhermore, early toolkits typically Applications that will work (even if somewhat slowly) did not handle image rendering at all, exposing this always trump applications that won’t run at all, from the disparity of displays completely to applications. point of view of an ISV (who wants to sell product), or an open source developer who wants their application Resource ID’s (for windows, pixmaps, fonts, etc) used widely. and Atoms are per server identifiers, and have to be remapped. These were typically exposed directly to applications, though sometimes with some abstrac- 2.2 Historical Observation about Opaque tion (for example, partially hidden in a widget data Server side fonts structure). Pseudocolor displays again presented toolkits, ap- From the beginning, X’s minimalist font abstraction has plications, or pseudoservers major headaches: there presented challenges to applications interested in serious would be no guarantee the color resources would typography. Due to X’s inadequacies, serious applica- be available when needed. It took longer for pseu- tions from the very beginning of X’s history have had to docolor to become unimportant than expected due work around X’s fonts, and coordinating X’s fonts with to the not fully understood economics that drove those required for printing has been a 15 year long mi- displays down market at the same functionality. graine headache. Thankfully, monochrome (1 bit) and pseudocolor displays are now a thing of the past, for all intents Applications need sufficient information for either X’s and purposes. use, or for printing use (something we ignored in the de- sign of the X protocol). Therefoer, to be useful to appli- cations on systems, any access to fonts must be able to access any information in the font files, since they will 2 Client Side Fonts continue to evolve. There have already been four generations of font formats While server side fonts clearly provide major headaches over X’s history: for migration and replication (since there is no guarantee that the fonts the application needs are available on the X servers being used), client side fonts are needed on Bitmap 1983-1990 general architectural grounds. This section lays out why. Speedo 1991 Type1 1992 2.1 Large Scale Distributed Systems Deploy- ment TrueType 1997 In large scale commercial systems, applications are often OpenType, in the short term future, represents a fifth for- run remotely from the X server to a desktop system or mat. Approximately every 5 years, there is likely to be X terminal, and therefore applications won’t be deploy- a new generation of and format for font files, with in- able until both ends of the communications have been creasing quality (along some dimension, whether it be updated. The X Window System, due to its network typographic, or character set, . ). Any server side font transparency, presents the problems of large scale dis- solution, therefore, will always be difficult to deploy in tributed systems. It is infeasible to update all X servers this distributed environment and will end up chasing a to support new font technology. moving target. As each new font technology has deployed, applications incremental behavior: no long startup delays for have needed to access the new data contained in the font font rendering, files for the new information. X itself has not evolved to do more than rendering the bits on the screen, and has as a result, much faster startup time, made it difficult or impossible for applications to share applications can directly access font files to enable this information. printing, Over this period, fonts themselves have become much future font formats can be added without larger. When X was designed, fonts typically had fewer client/server deployment interdependencies, than 128 glyphs (ASCII), and the number of fonts were an application is guaranteed that the fonts it needs small, and, since the fonts were bitmap fonts, the metrics will be usable on any X server in the network, eas- were static. The number of round trips to retrieve font ing migration and replication of applications. metrics were small, and the size of the metrics them- selves were small. This situation contrasts greatly with the present. 2.3 Remaining work Many modern fonts have thousands of glyphs and com- mon desktop systems may have hundreds or even thou- Some data from modern applications show these ben- sands of fonts. Searching among these fonts for correct efits [Pac00a] at current screen resolutions (typically style and code point coverage requires applications to 100DPI); more data on a wider selection of applications retrieve (typically at startup) very large amounts of met- is needed to confirm this early data.