Comparing Creator with the ZX Accelerator

Unlike the ZX accelerator, the built-in factory default visual on the Creator accelerator is not an overlay. On the ZX accelerator, the default visual is the overlay 8-bit PseudoColor visual. But on the Creator accelerator, like the SX accelerator, it is the 8-bit underlay PseudoColor visual. Thus, if you want to create applications with pop-up windows that are non-damaging with underlay windows, you cannot simply use the default visual. Instead, applications should call XSolarisOvlSelectBestOverlay to find a non-damaging overlay visual. Refer to the Solaris documentation on the OVL extension to X.

XSolarisOvlSelectBestOverlay was first introduced in Solaris 2.4. If an application needs to run on Solaris 2.3 or earlier as well as on Solaris 2.4, define the external reference to this function as #pragma weak. The program can then check the value of this symbol. If this symbol has the value of 0, then the program is running on Solaris 2.3 or earlier. In this case, XSolarisOvlSelectBestOverlay cannot be called to find the overlay visual. Instead, the application can use XGetVisualInfo to find the first 8-bit visual with less than 256 colormap entries. However, this technique is specific to the Creator accelerator and is not portable to other devices.

Window Manager Implications

Because the Creator accelerator default visual is not an overlay, problems occur when overlay windows are not override-redirect (i.e., wrapped with a window manager decoration window). The Solaris-supported window managers olwm, mwm, and dtwm always wrap toolkit subwindows with decoration windows in the default visual. This occurs even if an application specifies a non-default visual for the pop-up window.

For example, when the default visual is 8-bit underlay PseudoColor, the window manager will wrap it with an 8-bit underlay decoration window even if an application specifies to a toolkit that a pop-up window is to be placed in the 8-bit overlay PseudoColor visual. Thus, the pop-up continues to damage other underlay windows, which is not the intended effect.

Use the following workarounds to this limitation:

• Require that the end user configure the default visual as the overlay visual by typing the following before starting the window system:

  /usr/sbin/ffbconfig -defoverlay true

Keep in mind that the overlay visual has less colormap entries than the underlay 8-bit visual. Thus, the default colormap may fill up sooner, which may lead to increased colormap flashing.

• Rewrite the application to create override redirect pop-ups and manage them directly through Xlib, bypassing the toolkit.