11 X Window Displays

11.1 Pseudocolor

The pixel value in the frame buffer selects an entry in a colour table which contains the intensities of the three primary colours (Red, Green, Blue). This is how the traditional image display from the days before X worked and there are typically 8 planes in the frame buffer and therefore 256 entries in the colour table. Each colour table entry typically has 8 bits for each component giving 256 levels of red, 256 of green etc. Put another way, at any one time you can have up to 256 different colours out of a palette of 10${}^{24}$ ($\sim$16 million) possible colours.

11.2 Grey Scale

This is the same as pseudocolor except that only only one of the primary colours drives the monitor. Since colour monitors are cheap these days (can you get a monochrome monitor for a PC now?) it is of little interest.

11.3 Static Grey

Like Grey Scale but you can’t change the colour table—its contents are fixed at some values chosen by either the video adapter manufacturer or the writer of the X server. Even less interesting than grey scale.

11.4 Directcolor

The frame buffer pixel value is divided into three fields; one for each primary colour and each of the fields selects an entry in a separate lookup table each of which holds the intensity of the appropriate primary colour. A typical configuration is a frame buffer with 24 bits per pixel divided into three 8 bit fields each of which addresses a 256 entry colour table with 8 bits per entry. Such a configuration will be described by a manufacturer as supporting 2${}^{24}$ (16 million) colours out of a palette of 16 million.

11.5 Truecolor

This is like Direccolor but with the contents of the colour tables fixed.

11.6 What does this mean for you?

Until a few years ago, the best an astronomer could hope for was an 8-bit frame buffer which supported pseudocolor and most applications were written to work with this colour model. Unfortunately, an application that wants to change the colour table has to be aware of whether it is using pseudocolor or directcolor and supporting both in the same application is not trivial—different X lib calls are needed for setting the colour tables in the two models and the way that images are formatted is different. This means that there are still plenty of application in use that display pseudocolor on a directcolor or truecolor display. Most modern hardware supports both pseudocolor and directcolor with a 24 bit frame buffer and you are typically given the choice of either 8 bit pseudocolor or 24-bit directcolor (or 24-bit truecolor—more on this later). But why not 24-bit pseudocolor I hear you ask—the answer lies in the the amount of memory required for the colour tables. For 8-bit pseudo-colour you need (assuming 8 bits per colour) 768 bytes (3$\times$256); for 24-bit directcolor you need the same but for 24-bit pseudocolor you would need a little over 40 Mbytes! (3$\times$2${}^{24}$). So, how is it that direct-colour can give you 16 million colours with less that a Mbyte of colour table while pseudocolor need more than 50 times this to give you the same number of colours? Where’s the catch?

Consider what happens when you want to change the colour of something drawn on the screen. When using pseudocolor you change the colour table entry addressed by the pixel value used to draw the object—only things drawn with that pixel value change colour. However, with directcolor this is not true—if, for example, you change the red colour table entry for the selected pixel value not only do the things drawn with that pixel value change but anything drawn with a pixel value with the same value in the red component also changes—and there are 65 thousand pixel values that satisfy this condition. The end result is that if you want to be able to change the colours of things without effecting the colours of anything drawn with a different colour you find that you are back to only 256 colours—exactly what you get with 8-bit pseudocolor (and for 1 third of the video memory).

So, for a typical astronomical image display application which enables you to adjust the colour table interactively you are no better off using a 24-bit display than you are with an 8 bit one. This is not quite true because most applications have some fixed colours and you can potentially use up fewer colour table entries for the same number of fixed colours.

Running X server has a "default visual" (and hence colour model) but may support the creation of other windows with other colour models. However, not all applications are capable of requesting a visual type other than the default. An important exception is applications written in tcl/tk which has a -visual qualifier that enables you to select the visual type when you start the application. One undesirable consequence of running applications with different visual types on the same display is “colour flashing” where as the focus moves to one application the display of others is garbled. This effect is only absent on very high-end hardware.

Many X servers allow the default visual type to be specified when they are started (sometimes indirectly by specifying the frame buffer depth—e.g. 8 implies pseudocolor while 24 implies truecolor). The choice of truecolor rather then directcolor for the 24-bit mode may, at first, sight seem surprising. The reason is that with 8 bits per colour component in the frame buffer and 8 bits per colour in the colour table you can load the colour tables so that every possible intensity is available simultaneously and applications can draw in every one of the 16 million different colours simply by drawing with the right pixel value. Since the colour tables can’t be changed, all applications are guaranteed to have the full palette available—with a directcolor model the available pallet may have been reduced by some other application allocating entries for its own exclusive use. Unless applications are going to change the colours of things after they have been drawn—and most don’t (animation of button presses and the like are done by redrawing with a different pixel value)—you are better off with truecolor.

To find out what visual types an X server supports, run xdpyinfo (part of the X software) and don’t assume that you will necessarily get the same set if you start the server with a different default.

None of the above applies to MS Windows or NT (or Macs)—they handle colour allocation in a quite different way and may well exploit the capabilities of your video adapter rather better—after all it was probably designed to work with Windows from the start.

11.7 Pseudo Colour applications on True Colour desktops

Some applications, including several Starlink supported ones, were designed to be used on Pseudocolor displays. While this is not a problem on the Sun, DEC or NCD hardware, most of which supply a Pseudocolor display by default, the newer Linux machines supplied by Starlink are usually configured to take full advantage of their superior graphics hardware and provide Truecolor displays by default. Trying to use applications which were designed to run uder Pseudocolor displays on a Truecolor desktop may cause the program to display poorly, fail to run, or in extreme cases crash the X server.

There are several approaches to this problem. The least desirable option is to run your Linux X server in Pseudocolor (so called 8 bpp) mode by starting X Windows using the following command:

this does mean however that you are not utilising your graphics hardware at it best performance. This is somewhat irritating, hence there is a second (better) approach to the problem, you can run two different X servers on the same machine at the same time.

Linux offers the ability to use virtual consoles, these enable you to have several simultaneous sessions on the same machine. You can change between sessions by hitting Alt-F$\star$, e.g. Alt-F2 (hold down the Alt key and press the F2 key), or if you are in X Windows Ctrl-Alt-F$\star$.

So how does this help us run multiple X servers? Login to your Linux machine as normal and start X Windows using the startx command. Once X Windows has booted, hit Ctrl-Alt-F2 to switch to a second virtual console, and login again. Once you’ve logged in start a second X server, this one in 8 bpp mode, using the following command:

You can now switch between the two X servers using Ctrl-Alt-F7 (the original Truecolor X server on :0) and Ctrl-Alt-F8 (the Pseudocolor X server on :1). Applications can even be started in an xterm on one X server and displayed in another by using the -display localhost:0 and -display localhost:1 command line options, which most X applications will accept.

You should note that your system administrator may have configured your Linux box to automatically start a Pseudocolor display. If so you can follow the instructions above towards the opposite goal, having a Truecolor display on :1 by starting the second X server using the following command:

or if you have more graphics memory (and your X server has been configured to use it):

There is a down side, since you are now running two X servers you are using twice as much memory, it is inadvisable to try this approach on machines with only a small amount of system memory (RAM). However, yet another additional solution to the problem of Pseudocolor applications and Truecolor desktops is presented in Section 12.1.