The color-maps are perhaps the most environment sensitive parts of Tina and have had to be modified to keep pace with hardware and operating system changes. For this reason this area deserves additional explanation. Under an X11 server, Tina will attempt to request a dynamic cell colour-map (Pseudo_Color). This is done at the point where the display panel and visual are requested from the server (see tw_canvas). If succesful 256 cells will be allocated (cmap_create()) and then filled according to the required RGB values. These values will swap in and out as the active Tv panel (or other X graphics panel) changes. This is a fundamental limitation of 8 bit graphics displays. There are only 256 colour cells available for the entire system and all packages must share them. An attempt is made to copy at least some of the lower cells in the default colour-map cells to the new colour-map in order to minimise flickering. The number of default colours can be modified using the View Tool. This strategy used to be a good one, but unfortunately, many recent window managers spatter frequently accessed colours all over the cell array rather than grouping them in the lower cells, making it difficult to avoid flickering. Some of these cells may even be used to define the colours of the tools causing problems with legibility of buttons. Also some common packages seem to have the capability to permanently modify the system colour-map leading to similar problems. Packages certainly cannot be used together usefully, particularly when requiring a graphics dump. This has presumably been tollerated due to the general trend away from 8 bit graphics with recent improvements in hardware which elimiate these problems (see below). The View Tool contains a postscript dump facility so that the need to use other X based packages for graphics storage can be avoided.
If dynamic colour-map generation is unsuccesful and a static colour-map is returned (True_Color), it is assumed that the X server is running with at least a 16 bit colour-map and this default colour-map is THE system colour-map. 2.1. Pixel values are then found by searching for the closest RGB values in the default colour-map. The same colour-map types are available as for the 8 bit colour space so we still use a maximum of 256 colours. No attempt to copy the default colour-map is necessary and the space saved in the standard look-up table is used for extra colours. There is no flickering, but a red overlay plane can no longer be explicitly allocated and the XOR process simply generates a pixel value for a colour cell which is very dissimilar to the original.
X is particularly sensitive to attempts to query or allocate non-existent colours. In addition the nearest pixel value returned by X server queries is not hardware independent and endian swapping may be neccesary when using 16 bit colour-maps (or greater) on remote X servers. Clearly, 16 bit data may also increase the quantity of data transmitted from the server for a given image size.