Chapter 3

Visuals on the Solaris X Server

This chapter discusses X window visuals on the Solaris X server. The chapter includes information on the following:

Default visual
Visuals on multi-depth devices
Gamma-corrected visuals
Hints on window programming with visuals

About Visuals

A display device can support one or more display formats. In the X window system, the display formats supported by the window server are communicated to client applications in the form of visuals. A visual is a data structure describing the display format a display device supports.

When an X11 client creates a window, it specifies the window's visual. The visual describes the display characteristics for each pixel in the window. In other words, a window's visual instructs the display device's video hardware how to interpret the value of the window's pixels.

For each display device configured into the system, there is an X11 screen. For each screen, a list of supported visuals is exported by the server to client applications. This list of visuals tells the client application which display formats are available for creating windows.

The visuals exported by the server for a display screen are not fixed; they depend on the screen's device handler. Since the exporting of visuals is under the control of the device handler, client applications must be prepared to deal with a wide variety of visuals, including visuals with depths other than those that have previously been common, such as 1, 8, and 24 bits. Visuals with depths of 4, 16, and odd depths may not be exported, and clients must be prepared to handle them.

Client applications can query the list of supported visuals for a screen by calling the Xlib routines XGetVisualInfo(3) or XMatchVisualInfo(3), and can query the list of supported visuals using the utility xdpyinfo(1). For general information on color and visuals in X11, see the X11 documentation listed in the preface to this manual.

Default Visual

For each X11 screen, one of the exported visuals for the screen is designated the default visual. The default visual is the visual assigned to the screen's root window, and this visual is the visual that most applications use to create their windows. When a client application starts, its windows are assigned the default visual unless the application specifies a different visual.

The built-in default visual is the visual hard-coded in the Solaris X server. For each screen, there is a default visual that depends on the characteristics of the display device for that screen. This is the default visual unless you specify a different default visual when you run openwin(1).

Users can change the default visual that window server advertises in the connection block. One reason for this is to force client programs that cannot run in the default visual to run in a specific visual. For example, on a 24-bit device that has the TrueColor visual as its default visual, an application that cannot run with 24-bit color may run on a PseudoColor visual.

For developers on multi-depth devices, changing the default visual is a useful way to test that your application works in different configurations. For information on how to change the default visual, see the xsun(1) man page. The default visual and the list of supported visuals exported by the server can be examined from X11 using XGetVisualInfo(3).

Visuals on Multi-Depth Devices

The Solaris X server supports devices that can display windows of more than one pixel depth simultaneously. These devices are called multi-depth devices. Since most of these devices are implemented with separate groups of bit planes for each depth, the term multiple plane group (MPG) device is often used for these devices.

For each depth, there might be one or more visuals exported. For most MPG devices, windows can be created using any of the exported visuals. For applications that prefer a TrueColor visual, the developer should determine whether the TrueColor visual is available, since it may be available even if PseudoColor is the default visual.

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.

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

Gamma-Corrected Visuals

The linearity attribute of a visual describes the intensity response of colors it displays. On a cathode ray tube (CRT) monitor, the colors displayed are actually darker than the colors requested. This darkening is caused by the physics of monitor construction. Some devices support visuals that compensate for this darkening effect. This is called gamma correction.

Gamma correction is done by altering colors coming out of the frame buffer with the inverse of the monitor's response. Because the overall intensity of a gamma-corrected visual is a straight line, a gamma corrected visual is called a linear visual; a visual that is not gamma corrected is called a nonlinear visual.

Linearity is not a standard X11 attribute for visuals. However, some applications require a linear visual to avoid visible artifacts. For example, a graphics application using antialiased lines may produce objectionable "roping" artifacts if it does not use a linear visual. This kind of application is called a linear application. An application requiring a nonlinear visual for best display of colors is called a nonlinear application. Most X11 applications are nonlinear applications.

On most devices, the linearity of default visuals is nonlinear. Therefore, linear applications should not depend on the default and should always explicitly search for a linear visual. Similarly, it is a good idea for nonlinear applications to explicitly search for a nonlinear visual. Since this is typically the default on most devices, it is not as critical, but it is still a good policy to do so.

To determine whether a visual is linear, applications can use the interface XSolarisGetVisualGamma(3). For more information on gamma correction, refer to Fundamentals of Computer Graphics by Foley and Van Dam.

Visual Selection Alternatives

It is recommended that applications be written to handle a wide variety of visual configurations. Some devices, for example the GX, do not have any linear visuals. Other devices have only a single linear 24-bit TrueColor visual. Other types of devices may support both linear and nonlinear visuals at the same time. In general, the most prudent way to write a portable application is to deal gracefully with all these configurations. This may involve printing a warning message if the visual of the desired linearity is not found. Or, if a linear application cannot find a linear visual, a useful trick is to manually darken in the application the colors given to X11. This is tantamount to performing your own gamma correction. The gamma value returned by XSolarisGetVisualGamma can be used to determine how much to darken the colors.

Note - XSolarisGetVisualGamma is a Public interface of Solaris and is fully supported. In the future, a color management system may also provide this functionality. When this occurs, this will become the preferred way of getting this information. But until then, XSolarisGetVisualGamma should be used. When this color management system is introduced, applications using XSolarisGetVisualGamma will continue to run with no modification and will actually benefit from the increased accuracy of the color management system.