Overlay Troubleshooting

• Colormaps. Overlays have their own colormaps. You therefore should call XSetWMColormapWindows() to create the colormap, populate it with colors, and to install it.

  Note: Overlays on Silicon Graphics systems reserve pixel zero as the transparent pixel. If you attempt to create the colormap with AllocAll, the XCreateColormap() function will fail with a BadAlloc X protocol error. Instead of AllocAll, use AllocNone and allocate all the color cells except zero.

• Window hierarchy. Overlay windows are created like other windows, their parent window depends on what you pass in at window creation time. Overlay windows can be part of the same window hierarchy as normal windows and be children of the normal windows. An overlay and its parent window are handled as a single hierarchy for events like clipping, event distribution, and so on.

• Color limitations. On low-end Silicon Graphics systems, there are only a few overlay planes available; thus, items drawn in the overlay planes (such as menus) usually use only a few colors--no more than three colors and the transparent pixel in some cases. More recent low-end systems (24-bit Indy(TM) graphics), mid-range systems (Indigo2 IMPACT(TM)), and high-end systems (RealityEngine(TM)) support 8-bit overlay planes.

• Input events. The overlay window normally sits on top of the normal window. Thus, it gets all input events such as mouse and keyboard events. If the application is only waiting for events on the normal window, it will not get any of those events. It is necessary to select for events on the overlay window as well.

• Not seeing the overlay. Although overlay planes are conceptually considered to be "above" the normal plane, an overlay window can be below a normal window and thus clipped by it. When creating an overlay and a normal window, use XRaiseWindow() to ensure that the overlay window is on top of the normal window. If you use Xt, you must do this after the widget hierarchy has been realized.