Hints for Windows Programming With Visuals

This section discusses various issues that may arise when programming X11 applications for devices that support more than one visual.

Default Visual Assumptions

A common mistake in programming an X11 client is to assume that the default visual has an indexed class (for example, PseudoColor or StaticColor). It is possible for the default visual to be 24-bit TrueColor on some devices. Clients expecting to run on these devices must be prepared to handle this type of default visual.

Other common programming mistakes with visuals are:

• Assuming the default depth is 8

• Assuming the colormap is writable

• Using a default visual that is not appropriate rather than searching for an appropriate visual using XGetVisualInfo

If the device does not support a visual requested by a client, the following error message is returned. In this error message, # represents the depth number requested, and n represents the requested display device. If this message is returned for a supported visual/device combination (as indicated in Table A–1), then an installation problem exists.

Error:

cannot provide a default depth #for device

/dev/fbs/n

In general, client applications may need to be modified to make them more portable in the presence of different default visual types.

Setting the Border Pixel

When creating a window with a visual that is not the default visual, applications must set the border_pixel value in the window attribute structure, or a BadMatch error occurs. This is a common programming error that may be difficult to debug. For information on setting the border pixel, see the XCreateWindow man page.

If you are experiencing improper graphics and double-buffering performance (such as lack of acceleration), OpenWindows might not have been installed as root.