JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Solaris X Window System Developer's Guide
search filter icon
search icon

Document Information


1.  Introduction to the Solaris X Server

2.  DPS Features and Enhancements

3.  Visuals on the Solaris X Server

4.  Font Support

5.  Server Overlay Windows

6.  Transparent Overlay Windows

What are Transparent Overlay Windows?

Basic Characteristics of Transparent Overlay Windows

Paint Type


More on Transparent Overlay Characteristics


Window Border

Backing Store

Window Gravity


Input Distribution Model

Print Capture

Choosing Visuals for Overlay/Underlay Windows

Example Program

Overview of the Solaris Transparent Overlay Window API

Creating Transparent Overlay Windows

Setting the Paint Type of a Graphics Context

Setting the Background State of a Transparent Overlay Window

Rendering to a Transparent Overlay Window

Querying the Characteristics of a Transparent Overlay Window

Determining Whether a Window is an Overlay Window

Determining the Paint Type of a Graphics Context

Pixel Transfer Routines

Filling an Area Using the Source Area Paint Type

Copying an Area and Its Paint Type

Retrieving Overlay Color Information

Using Existing Xlib Pixel Transfer Routines


XCopyArea and XCopyPlane

Designing an Application for Portability

Selecting a Visual for an Overlay/Underlay Window

Argument Types

Return Types

Multiple Criteria Sets

Selecting an Optimal Overlay/Underlay Visual Pair

Argument Types

Return Types

Criteria Sets

7.  Security Issues

A.  Reference Display Devices



Choosing Visuals for Overlay/Underlay Windows

The Solaris transparent overlay API supports multiple plane group (MPG) and single plane group (SPG) devices. Display devices come in a wide variety of configurations. Some have multiple plane groups. Some have multiple hardware color lookup tables (LUTs). Some dedicate color LUTs to particular plane groups and some share color LUTs between plane groups. This wide variety makes it difficult for an application writer to construct portable overlay applications.

For a given type of underlay window, some devices can provide some types of overlay windows with high-performance rendering. Other devices provide the same type of overlay window but with slower rendering. Some devices can support overlays with many colors, and some devices cannot. Some devices can support simultaneous display of both overlay and underlay colors for all types of overlays and underlays. Others support simultaneous display of colors but not for all overlay/underlay combinations. Still others support a certain degree of simultaneous color display. These devices support more than one hardware color LUT. Hardware might not contain enough color LUTs to enable all applications to display their colors simultaneously.

The following routines enable an application to negotiate with the system for a suitable overlay/underlay visual pair:

These routines are described in the section Designing an Application for Portability.

The assumption is made that each application has an ideal configuration of windows and colors. An application should start out by asking for the “best” overlay/underlay pair. If this can be satisfied by the device, then the negotiation is complete, and the application proceeds to create windows on the selected underlay and overlay visuals. But if no visual pair satisfies the query, the application must relax its demands. To this end, it should specify the “next best” pair. The application may choose to ask for less colorful visuals, or it may accept lower rendering performance on one of the visuals. The process continues until either a satisfactory visual is found, or the application decides it's not worth running in this environment without certain criteria being met.

The transparent overlay API provides routines that enable the application to conduct such a negotiation in a single subroutine call. The application specifies criteria to be matched for either the overlay visual, the underlay visual, or both. Application programmers are encouraged to use these routines to ensure portability to the widest range of graphics devices.