In this sections the current issues are outlined that require further investigation.
The font path and glyphs need to be the same for the front-end and each of the back-end servers. Font glyphs could be sent to the back-end servers as necessary but this would consume a significant amount of available bandwidth during font rendering for clients that use many different fonts (e.g., Netscape). Initially, the font server (xfs) will be used to provide the fonts to both the front-end and back-end servers. Other possibilities will be investigated during development.
To allow pixmap and on-screen rendering to be pixel perfect, all back-end servers must render zero width primitives exactly the same as the front-end renders the primitives to pixmaps. For those back-end servers that do not exactly match, zero width primitives will be automatically converted to one width primitives. This can be handled in the front-end server via the GC state.
With very large tiled displays, it might be difficult to read the information on the standard X desktop. In particular, the cursor can be easily lost and fonts could be difficult to read. Automatic primitive scaling might prove to be very useful. We will investigate the possibility of scaling the cursor and providing a set of alternate pre-scaled fonts to replace the standard fonts that many applications use (e.g., fixed). Other options for automatic scaling will also be investigated.
Each screen's default colormap in the set of back-end X servers should be able to be adjusted via a configuration utility. This support is would allow the back-end screens to be calibrated via custom gamma tables. On 24-bit systems that support a DirectColor visual, this type of correction can be accommodated. One possible implementation would be to advertise to X client of the DMX server a TrueColor visual while using DirectColor visuals on the back-end servers to implement this type of color correction. Other options will be investigated.