Miscellaneous Topics

Double Buffer Extension (DBE)

DBE is an extension to the X server that provides a double-buffering Application Programming Interface (API). Note that MBX (the Multi-Buffering eXtension to X) has not been adopted as an industry standard, as DBE has. Thus, it is recommended that applications that use MBX be ported to DBE usage in preparation for future MBX obsolescence (HP-UX 11.0). For more information about DBE and the API, consult the DBE man pages:

DBE
XdbeQueryExtension
XdbeGetVisualInfo
XdbeFreeVisualInfo
XdbeAllocateBackBufferName
XdbeDeallocateBackBufferName
XdbeSwapBuffers
XdbeBeginIdiom
XdbeEndIdiom
XdbeGetBackBufferAttributes

Performing Buffer Swaps On Vertical Blank

For performance reasons, the default DBE behavior is to not synchronize buffer swaps with the monitor's vertical retrace period. In some instances, therefore, image tearing (seeing part of the old image and part of the new image on the display at the same time) could be visible while swapping large DBE windows. For those instances where tearing would occur and is undesirable, an optional X server mode is available to allow for synchronization of buffer swaps with vertical retrace. To activate this optional X server mode, set the following screen option in the X*screens File before the X server is started:

SwapBuffersOnVBlank

Note that MBX_SWAP_BUFFERS_ON_VBLANK is obsolete with this release. The SwapBuffersOnVBlank Screen Option works for both DBE and MBX.

Display Power Management Signaling (DPMS)

Monitors constitute a large percentage of the power used by a workstation even when not actively in use (i.e., during screen blanking). In order to reduce the power consumption, the Video Electronic Standards Association (VESA) has defined a Display Power Management Signaling (DPMS) standard which can be used to greatly reduce the amount of power being used by a monitor during screen blanking.

The X server features the ability to make use of DPMS on the following graphics devices:

The following table is a description of the states that are defined by VESA. The Power Savings column indicates (roughly) the level of power savings achieved in the given state. The Recovery Time is the amount of time that the screen takes to return to a usable state when the screen saver is turned off (by pressing a key or the moving the mouse).

The actual amount of power saved and the recovery time for each of the states is monitor-dependent and may vary widely. The customer can compensate for this by choosing an appropriate level for the monitor that is currently in use.

By default, the DPMS level used is the Screen Saver (i.e. no power savings). If you wish to use power saving during screen blanking, set the following X*screens file entry before starting the server:

MinimumMonitorPowerSaveLevel 〈level〉

where 〈level〉 is replaced with the single digit 0, 1, 2, or 3 as specified in the Level column in the above table.

MBX

The MBX extension (Multi-Buffering Extension) is supported on all graphics devices supported on the HP 9000/700 machines, except the PersonalVRX and the TurboVRX.

HP's implementation of MBX exists mainly to support fast double-buffering for PEX applications. Therefore, MBX only supports allocation of one or two MBX buffers; no more. Some graphics devices/visuals have a single 8-plane buffer; this includes the color graphics device and the overlay planes on the CRX-24[Z], CRX-48Z, HCRX, and HP Visualize family. For these devices, MBX double-buffering is still supported, but the second bank is allocated in virtual memory. Rendering and buffer-swapping in these instances is slower than devices/visuals that support true hardware double-buffering.

There is no easy way to determine which visuals, from a device's list of visuals, support fast MBX hardware double-buffering. The CRX and Dual-CRX device is a double-buffered device and therefore always supports MBX hardware double-buffering. The Internal Color Graphics, Integrated Color Graphics or Color Graphics card devices only support MBX software buffering. All other devices that have both overlay and image planes support fast MBX hardware double-buffering in the image planes and slower MBX software double-buffering in the overlays. Consult the following device-specific sections for a list of visuals that support software and hardware MBX double-buffering.

For performance reasons, the default MBX behavior is to not synchronize with the monitors vertical retrace period. In some instances, image tearing could be visible while swapping large MBX windows. For those instances where tearing would occur and is undesirable, an optional X server mode is available to allow for synchronization with vertical retrace. To activate this optional X server mode, set the SwapBuffersOnVBlank Screen Option in the X*screens file before the X server is started.

Note that MBX_SWAP_BUFFERS_ON_VBLANK is obsolete with this release. The SwapBuffersOnVBlank Screen Option works for both DBE and MBX.

With this mode enabled, all MBX buffer swaps are synchronized with the monitor's vertical retrace period.

This mode is not needed in drawables used for PEX rendering. PEX turns synchronization on and thus does not require this tuning.

The MBX Application Programming Interface is thoroughly discussed in the PEXlib Programming Manual by Tom Gaskins, and published by O'Reilly & Associates, Inc. Consult that manual to understand the creation, manipulation, and destruction of MBX buffers.

Since MBX is not an industry standard, and will be discontinued on HP-UX 11.0, developers should replace MBX calls with the appropriate DBE calls.

	NOTE: Note that XmbufGetScreenInfo() can indicate that a window supports MBX even if only one MBX buffer is supported. An application should always check the max_buffers field in the returned XmbufBufferInfo structure before assuming that a window supports two MBX buffers.

Shared Memory Extension (MIT_SHM)

The MIT shared memory extension provides both shared-memory XImages and shared-memory pixmaps based on the SYSV shared memory primitives.

Shared memory XImages are essentially a version of the XImage interface where the actual image data is stored in a shared memory segment, and thus need not be moved through the Xlib interprocess communication channel. For large images, use of this facility can result in increased performance.

Shared memory pixmaps are a similar concept implemented for the pixmap interface. Shared memory pixmaps are two-dimensional arrays of pixels in a format specified by the X server, where the pixmap data is stored in the shared memory segment. In all other respects, shared memory pixmaps behave the same as ordinary pixmaps and can be modified by the usual Xlib routines. In addition, it is possible to change the contents of these pixmaps directly without the use of Xlib routines merely by modifying the pixmap data.

Shared Memory Transport (SMT)

Shared Memory Transport (SMT) is a means to more rapidly transport large amounts of data from the client to the server. It is distinct from the MIT Shared Memory Extension, which is specifically for various types of images, although SMT can be used with that extension.

SMT is particulary advantageous for operations that move large amounts of data in a single request, such as a polyline or a polypoint, and for images when the MIT Shared Memory Extension is not used. It will work with the Big Requests Extension, but whether it will exhibit a performance increase depends on the size of the actual extended size request. There are some X requests for which no improvement is expected.

SMT is the default transport for 10.20 whenever a display name of any of the forms listed below are used, and when the client and server are actually on the same host. Note that ":0.0" is used for simplicity. This behavior is equally applicable for displays such as ":1.0", etc.

A display name of the form unix:0.0 will force the use of Unix Domain Sockets (UDS), which is identical to the local transport used before HP-UX 10.20.

A display name of the form nn.nn.nn.nn:0.0 (where nn.nn.nn.nn is an IP address) will force the use of Internet Sockets, which is the remote transport normally used, and which can be used locally. (This will be slow.)

It is possible that an application which violates the X interface standard will run correctly using UDS but hang or coredump when using SMT. Users encountering this problem can use:

DISPLAY=unix:0 〈command_and_args〉

to run the application compatibly, but without the performance improvement of SMT.

Note that if neither SMT nor UDS are desired, setting XFORCE_INTERNET=True before starting the X server forces all protocol to interact directly with the hardware internet card.

SMT uses file space on the file system containing /var/spool/sockets/X11. Should it be the case that that file system is full, the X server will use Unix Domain Sockets (UDS) but print a warning (in /var/vue/Xerrors if VUE is in use or /var/dt/Xerrors CDE is in use) on each connection startup. To address this (and if space cannot be made), /var/spool/sockets/X11 can be a symbolic link to another file system with more space. If /var/spool/sockets/X11 is on a NFS file system, currently SMT will (silently) not start, and the connection will be made using Unix Domain Sockets. Again, a symbolic link to a conventional file system may be used to deal with this.

Performance Tuning of SMT

The default values of some buffer sizes have been tuned for optimal performance in most situations. However, these are not necessarily optimal in all conditions. Under some circumstances system performance might be optimized (possibly at the expense of X performance) by tuning these parameters. Under most circumstances this should be unnecessary.

The Server accepts these parameters via the X*screens file, in the ServerOptions section. In this case, the default for all SMT connections is set.

The client accepts these parameters via the environment variable X_SMT_SIZES. For the client, the value affects all client connections to the server made while this environment variable is set.

In either case, the format and meaning of the fields is the same:

〈region_size〉[, 〈high_water〉 [, 〈buffer_size〉]]

with no embedded blanks. For example:

32000,16000,5000
32000
0

The default is 100000,90000,90000.

The values are accepted as positive decimal, hex, or octal values according to the C conventions.

The special value of 0 (for buffer size; all other values are ignored) indicates that SMT is to be suppressed.

The 〈high_water〉 value must fit within the region (and should be smaller), the buffer must fit within the high-water mark (and consequently the buffer must fit within the whole region).

If these parameters are used, be sure to confirm that they actually cause an improvement in actual usage situations. Incorrect values can degrade performance.

	NOTE: Begin Note for Programmers X Applications which call fork(), and access the same display structure from both the parent and the child cannot be expected to operate reliably without extreme care (if at all), whether or not SMT is used. However, SMT is more sensitive to this than UDS. The problem is quite similar to stdio, where fflush() must be used to assure that data makes it from the buffer onto the file exactly once. Similarly to stdio's use of fflush(), XFlush() (not _XFlush()) must be called immediately before any fork() call that will be accessing the display from both the parent and child, as well as any time control is transferred between the parent and child, or vice-versa. (Calls to fork() which immediately do an exec() are not a problem.) The SMT library code attempts to detect improper use of display connections after a fork, and issues a warning at runtime. However, not all all such usages can be detected. Symptoms include reporting the error, and applications hanging. Also, because the parent and child might read from the same display connection (either replies or events) the library can detect inconsistent sequence numbers, which it will report. It will attempt to recover from such errors, but depending on what the application has done, recovery cannot always be successful. Only for R5 Applications SMT requires a change to an internal interface with the X library. In theory, no application should be calling this interface, but some applications, including at least one X test suite, are known to call it. The interface is _XConnectDisplay. Applications using it directly may not be able to use SMT for the display specified, and must add an extra (ninth) parameter, which is the address of an integer: int dummy; _XConnectDisplay(..., &dummy); Symptoms include both damaged data and core dumps. (There was an earlier HP Shared Memory Transport, which this one replaces. It used the same parameter, so it may be the case that any such calls have already been fixed.) This problem does not occur in the R6 library. End Note for Programmers

HP Color Recovery

Color Recovery is a technique that generates a better picture by eliminating the graininess caused by traditional dithering techniques. It is available on these graphics devices:

Color Recovery is available when using either depth-8 PseudoColor or depth-8 TrueColor visuals.

There are two components to the Color Recovery process. First, a different dither-cell size (16×2) is used when rendering shaded polygons. Second, a digital filter is used when displaying the contents of the frame buffer to the screen.

Under some conditions, Color Recovery can produce undesirable artifacts in the image (this also happens with dithering, but the artifacts are different). However, images rendered with Color Recovery are seldom worse than what dithering produces. In most cases, Color Recovery produces significantly better pictures than dithering.

Color Recovery is available by default for all depth-8 color visuals on devices that support the feature. If, for some reason, you wish to disable Color Recovery, set the DisableColorRecovery Screen Option in the X*screens file before starting the server (note that this disables Color Recovery for 3D APIs as well).

Color Recovery is enabled in conjunction with a particular X colormap that is associated with your window. If the X colormap is not installed in hardware, you may not see the effect of the Color Recovery filter (you may not even see the correct colors for that window). Given that more than one hardware colormap (or "color lookup table") is available, this should happen infrequently.

The Color Recovery colormap is a read-only colormap. Any attempts to change it will be ignored and no error will be reported.

Access to the Color Recovery capability is transparent when using a 3D graphics API such as Starbase, HP-PHIGS or PEX. If you are producing graphics using Xlib calls, your application must perform some of the necessary processing. The method to access Color Recovery via Xlib is described in a section called "Accessing HP Color Recovery Technology via Xlib" in the device-dependent sections.

Dynamic Loading

HP's X server now dynamically loads the appropriate device drivers and extensions based on the target graphics display device and the extensions the device driver supports. This feature should be transparent to X server users.

When possible, the loading of X extensions is deferred until the first protocol request is encountered for a given extension. This feature should be transparent to X server users; however, it is expected to provide some performance enhancement.

Dynamically loaded modules are recorded by the X server in the files"/var/X11/Xserver/logs/X*.log", where the "*" of X*.log reflects the display identifier for that given run. Only that last invocation against a given display identifier is retained. The log file contains the parsed contents of the given X*screens file and the full path name for all dynamically loaded modules for the given X server invocation. Deferred loaded modules are recorded as they are referenced.

	NOTE: Altering or removing files under /usr/lib/X11/Xserver may prevent the X server from running.

Include Inferiors Fix

When a client application creates an X Graphics Context (GC), it is possible to specify the subWindowMode component. The two possible values are ClipByChildren (default) and IncludeInferiors. If the GC specifies ClipByChildren, any rendering to a window with inferior windows (i.e., the child is wholly enclosed by the parent) will appear only in the destination window. In other words, the rendering will not take place inside the inferiors. If the GC specifies IncludeInferiors, and the same rendering request is made, it is the responsibility of the X Server to ensure that the rendering is not clipped from the inferior windows. In other words, the rendering will appear in the destination window and the inferior windows.

With the advent of multi-layer devices, the IncludeInferiors mode became defective. Depending upon which layer or hardware buffer the destination drawable and inferior windows were in, the rendering may or may not have taken place. Also, the GetImage protocol clearly specifies that the default GetImage behavior is to include the depth-dependant contents of inferior windows (in other words, GetImage requires that IncludeInferiors work properly).

As of the 10.10 release, HP has offered a solution to the IncludeInferiors defect. Some customers create their test image archives using XGetImage (which currently returns incorrect data for multi-layer and double-buffered devices). Therefore, the Include Inferiors Fix will not be enabled by default. To enable the Include Inferiors Fix, add the EnableIncludeInferiorsFix Screen Option to the X*screens file.

For example:

Screen /dev/crt/
    ScreenOptions
        EnableIncludeInferiorsFix

This gives a system administrator control over when the fix is active and when it is not. In this way, each site can evaluate whether or not it is beneficial to enable this fix.

Shared Memory Usage With 3D Graphics

Graphics processes use shared memory to access data pertaining to the display device and X11 resources created by the server. ("Resources" includes windows, colormaps, and cursors.) The X11 server initiates an independent process called the Graphics Resource Manager (GRM) to manage these resources among graphics processes. Graphics processes include PEXlib, PHIGS, and Starbase applications. One problem encountered with GRM shared memory is that it may not be large enough to run some applications.

Graphics applications that require VM double-buffering use large amounts of shared memory. Shared memory can be completely consumed by several double-buffered graphics windows. When an application attempts to use more shared memory than is available, the application encounters errors and might terminate.

You can circumvent the problem by using Server Options to change the shared memory size.

Changing Graphics Shared Memory Size

The size of the shared memory segment used by the GRM can be controlled through a Server Option. The default value is 0x580000 (5.5 Mbytes) on Series 700 computers.

	NOTE: The actual GRM shared memory size on a system can be determined by running "ipcs -ma", finding the entry with CPID matching the process ID of the grmd process and then checking the segment size (SEGSZ) field.

If more shared memory space is needed, graphics shared memory size can be increased. For example, to set it to eight megabytes:

ServerOptions GraphicsSharedMemorySize=0x800000

Note that the value must be in hexadecimal. The new value won't take effect until you restart the X Server.

It is also possible to decrease the size of GRM shared memory. You may want to do this if you want to reduce the swap-space requirements of your system and/or you do not intend to run any 3D graphics processes. For example, you could reduce graphics shared memory size to 0x100000 (one megabyte).

Count Transparent In Overlay Visual

In some configurations, an 8-plane overlay visual may have less than 256 colors. This should not cause a problem for most applications. If an application depends on 8-plane visuals having 256 colormap entries, this option may be useful. Setting this option will cause the X server to count transparent entries in the number of colormap entries.

Enable Overlay Transparency

This option is used to enable the usage of an overlay transparent color on devices that can support it, but, by default, do not allow it (for example, HCRX-8).

3-Bit Center Color

This option is available to force the X server to center colors in the colormap to values that will reduce the amount of twinkle on flat-panel conversion. This option applies only to flat-panel displays.

The twinkling effect is caused by the analog-to-digital conversion. Due to noise in the analog signal, it is possible for a color near a boundary between two digital values to cause the conversion to bounce back-and-forth between the two colors (i.e., "twinkle"). In order to avoid this effect, the server "centers" the colors as far from the color boundaries as possible.

Image Text Via BitMap

When using the Xlib XDrawImageString() call to draw text, a visual effect may be seen where text appears to flicker as the background and foreground are drawn in distinct graphics operations. This option is available to eliminate the flicker effect but at the expense of reduced text performance. The option will make the X server first draw text to an off-screen pixmap prior to displaying it to the screen.

	NOTE: Using this option will reduce text performance.

The ImageTextViaBitMap screen option is supported on all graphics devices supported on the HP 9000/700 machines, except the following:

Obsolete Environment Variables

These HP-UX 9.x environment variables are no longer supported:

HP_SUPPRESS_TRUECOLOR_VISUAL
HP_COLORMAP_MANAGEMENT_SCHEME
WMSHMSPC
MBX_SWAP_BUFFERS_ON_VBLANK
CRX24_COUNT_TRANSPARENT_IN_OVERLAY_VISUAL

Special Device Files

Special device files are used to communicate between the computer and peripheral devices. The X server requires the use of a special device file for each graphics card present in the system. On HP-UX 10.x systems, five special graphics device files are automatically created. The first or primary graphics card, also known as the "console", uses the "/dev/crt" or "/dev/crt0" device file. The others are called "crt1", "crt2", and "crt3" and also reside in "/dev". Those systems containing multiple graphics devices on a single card (Dual Color Graphics and Dual CRX, for example) need to have special device files manually created for them.

Special device files are created by using SAM (the System Administration Manager tool):