The 24-bit TrueColor visual of the Creator accelerator can display over 16 million colors simultaneously without colormap flashing. Furthermore, the Creator rendering engine is optimized for 24-bit rendering. Consequently, it is very desirable for users and X client programmers to use this visual.
Even though 24-bit TrueColor offers fast rendering and no colormap flashing, the built-in factory default visual on the Creator accelerator is 8-bit PseudoColor. This was done to accommodate X applications that don't handle a 24-bit visual properly. It is better to have programs run and colormap flash than to not run at all. Fortunately, the majority of desktop applications do run properly with this visual.
Users who desire less colormap flashing on their desktop can run the window system with the default visual configured to 24-bit TrueColor. This is the recommended mode of running the window system on the Creator accelerator.
Be aware of the following conditions when using this mode:
Some X applications cannot handle the 24-bit default. These type of programs usually fail to run and issue a BadMatch error message. Other programs may core dump or draw incorrect colors. If you encounter such an application, you can diagnose the problem by rerunning the application under the 8-bit PseudoColor default visual. If the program works, it probably cannot handle a 24-bit TrueColor default visual. Contact the application supplier and request an upgraded program. In the meantime, use the factory default 8-bit PseudoColor visual mode until the application is fixed.
When the default visual depth is 24-bit, pixmaps and window backing store will occupy four times the space as in an 8-bit depth. This usually does not increase the working set of the server, but it does increase swap space. If you run programs that use lots of pixmaps or backing store windows, stay in 8-bit mode.
X client programmers should strive to write programs that are 24-bit clean, so that they run properly when the default visual is 24-bit TrueColor.
A program might fail to be 24-bit clean for several reasons. Following are some programming practices to avoid:
Do not assume that the default visual is 8-bit PseudoColor.
Some programs only run in 8-bit depth because they have been ported from 8-bit-only systems and they have not been upgraded. Some programs might store their lists of pixels in a 256-element array. Other programs may require a modifiable colormap to perform colormap double buffering.
If your program requires 8-bit PseudoColor, check the depth and class of the default visual. If it's not the 8-bit PseudoColor visual, search the visual list until you find it.
Do not inherit the border pixel from the parent.
On a multiple plane group device like the Creator accelerator, the depth of the window you are creating may not match the depth of the parent window (which is often the root window). Unless you specify an explicit border pixel value, the border pixel value of the window is inherited from the parent. If the depths differ, XCreateWindow will fail with a BadMatch error. Always use XCreatewindow rather than XCreateSimpleWindow and explicitly specify a border pixel value.