[Graphics Admin Guide] [Prev] [Index] [Next]

Chapter 1: X Windows: HP-UX 11.0

Table of Contents


This chapter documents information specific to the HP X server. It describes features unique to HP's X server, provides information on how to configure the X server and includes a list of supported X configurations. For each supported graphics device, device-dependent configuration information is provided.

Information specific to a new release of the X server, beyond the scope of the general information in this document, can be found in the HP-UX Release Notes located in /usr/share/doc.

If you prefer to read this information on paper, see the Graphics Administration Guide. It includes the same information as is contained here in this on-line document.

(home) X Server Configuration

Configuration of the X server is supported through SAM via an icon titled "X Server Configuration". This icon resides either at SAM's top level or under the top-level "Display" icon. This location is determined by the version of the HP-UX operating system (later HP-UX releases will place "X Server Configuration" under the "Display" folder).

There are several X*screens files used to configure the operation of the X server. The SAM graphical user interface for X server configuration is provided to simplify complexity and facilitate ease of use. While it is still possible to modify these files manually (see below), using the SAM interface greatly simplifies the process for creating Multi-Display and Single Logical Screen configurations.

Our SAM component has the following actions:

Configure Print Server... Modify Multi-Screen Layout... Modify Server Options... Single Logical Screen (SLS) -> -------------------------------- Describe Screen... Identify Screen Modify Default Visual... Modify Screen Options... Add Screen to Configuration Remove Screen from Configuration The first group of actions can be thought of as "global" actions. They will typically be active regardless of what has been selected. If any of these menu items is not visible, it is because it is not supported under the current configuration. For example, on systems containing only one graphics screen, the last three menu items will not be visible.

The second group of actions can be thought of as "screen" actions. They will be activated depending on which screens have been chosen. It is also possible that the last two actions (Add and Remove) will be absent. When only one graphics screen is present, SAM will treat this screen as though it is always configured. Preselecting both configured and unconfigured screens will result in only the first two screen menu options being active.

(home) X*screens File

For manual changes, please refer to the sample files in the /etc/X11/ directory. Three files of particular interest are the X0screens, X0devices, and X0pointerkeys files.

(home) Description of the X*screens Configuration File

This file belongs in /etc/X11/X*screens, where "*" is the display number of the server. For example, the "X0screens" file is used when the $DISPLAY environment variable is set to hostname:0.screen and the server is invoked using the ":0" option.

The X*screens file is used to specify:

Note that all of the items above, except for device-independent server options, are specified on a per-screen basis.

The X server supports up to four screens at a time. Specifying more than four screens will cause a server error message.

(home) Syntax Guidelines

(home) The X*screens File Format

Items must appear in the X*screens file in the order that they are specified below.

[ServerOptions
server_option
...
server_option]
{Screen device_name} ||
{SingleLogicalScreen nRows nCols
device_name1 . . . device_nameN}
[DefaultVisual
[Class visual_class]
[Depth depth]
[Layer layer]
[Transparent]]
[MonitorSize diagonal_length units]
[MinimumMonitorPowerSaveLevel level]
[ScreenOptions
screen_option
...
screen_option]

Brackets ("[" and "]") denote optional items. Italicized items in angle brackets ("" and "") denote values to be specified. The double vertical line ("||") denotes that one of the ored values (items surrounded by braces, "{" and "}") must be included.

The block from the "Screen device_name" line to the final "screen_option" line is referred to as a either a "Screen Entry" or as a "Single Logical Screen entry". As shown above, the X*screens format is composed of an optional block specifying device-independent server options followed by one or more either Screen or Single Logical Screen entries (maximum of four graphics devices).

The minimum X*screens file is a line with the keyword "Screen" followed by a screen device file. For example:

   Screen /dev/crt

(home) Server Options

For more information about server options, or about additional server options, look in an information file (for example, /usr/lib/X11/Xserver/info/screens/hp).
GraphicsSharedMemorySize memory_size
Specify the size of the graphics shared memory region. The size must be specified in bytes and must be in hexadecimal.
Default value: 0x580000
Environment Variables Replaced: GRM_SIZE, WMSHMSPC.
SMTSizes size_spec
The size of the SMT regions (see the Shared Memory Transport section).
Default value: 100000,90000,90000
FileDescriptors number
The number of file descriptors available to the X server for its use. The number of connections (clients, more or less) is limited by the number of file descriptors.

The minimum value is 25, and a current maximum (as of HP-UX 10.20) of 384, allowing a maximum of slightly under 256 total connections to the server. The default value is 192 (which allows a few under 128 connections). If a value provided is out of range, the server yields a warning and continues using the minimum or maximum, as appropriate. There is, however, a limit of 128 clients that can connect.

The command line option -lf number also specifies the value.

ImmediateLoadDles
The Xserver delays loading of some X extensions until the first protocol request to the given extension is received. Specifying this server option forces all extensions to be loaded at X server startup. Immediate loading of X extensions is the historical behavior of the HP-UX 10.10 and 10.20 X servers.

(home) Screen Entries

The minimum screen entry is a line with the keyword "Screen" followed by a screen device file.

Optional specifications for default visual, monitor size, and device-dependent screen options may follow this minimal screen description line.

DefaultVisual
This optional part of the format specifies the default visual that the screen uses. Valid keywords following the "DefaultVisual" keyword are "Class", "Depth", "Layer", and "Transparent".

If no default visual is specified, then the standard default visual class, depth, layer, and transparency for the graphics device is used.

Not all default visual specifications will work on all devices.

If there is an error in a specification, look in an information file for more details (for example, /usr/lib/X11/Xserver/info/screens/hp), in case it is newer than the document you're now reading.

Class StaticGray | GrayScale | StaticColor | PseudoColor | TrueColor | DirectColor
Specify the class of the default visual.
Depth depth_value
Specify the depth of the default visual (for example 8, 12, or 24).
Layer Image | Overlay
Specify the layer of the default visual.
Transparent
Specify that a visual with an application-accessible transparent entry in the default colormap be used.

Specifications in the "DefaultVisual" section, except for "Depth", are ignored on VRX devices. See the "ScreenOptions" section below for VRX-related options.

MonitorSize diagonal_length Inches | MM
Specify the diagonal size of the monitor. After the "MonitorSize" keyword, you must specify the diagonal length of the monitor and then the units. Use this entry only if you are using a non-standard monitor.

MinimumMonitorPowerSaveLevel value
Specify the minimum power save level to be used by the monitor during screen blanking. You must specify a level of 0-3. If the option is not used, the default is level 0. On devices that do not support DPMS, this option will be ignored.

ScreenOptions
Screen options are device-dependent options that are documented in a file in the X server information directory (for example, /usr/lib/X11/Xserver/info/screens/hp).

(home) Sample X*screens Files

Below are several sample X*screens files that illustrate the new format.

(home) Miscellaneous Topics

(home) 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

(home) 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.

(home) Determining Swap Performance

The DBE API does not allow users to determine if double-buffering in a visual is through software or hardware. However, the API does provide a way to determine relative swapping performance on a per-visual basis. The XdbeScreenVisualInfo() function returns information about the swapping performance levels for the double-buffering visuals on a display. A visual with a higher performance level is likely to have better double-buffer graphics performance than a visual with a lower performance level. Nothing can be deduced from any of the following: the magnitude of the difference of two performance levels, a performance level in isolation, or comparing performance levels from different servers.

For more information, refer to the DBE man page on XdbeScreenVisualInfo().

(home) Supported Devices

The X server supports DBE on the following devices:

(home) 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).

Power-Saving States Defined by VESA
Level State DPMS Compliance
Requirements
Power Savings Recovery Time
0 Screen Saver Not Applicable None Very Short (<1 sec)
1 Stand-by Optional Minimal Short
2 Suspend Mandatory Substantial Longer
3 Off Mandatory Maximum System Dependent

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.

(home) 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 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.

(home) 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.

(home) Supported Devices

The X server supports the MIT shared memory extension on the following devices:

(home) 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.

(home) 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 examples:

    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.

region_size
controls the amount of shared memory allocated for the transport (in bytes). This has the largest effect on system performance. The value is rounded up to the next page boundary. Larger values yield faster X performance but there is a point of diminishing returns. The default is 100000 (which is rounded to 0x19000).

high_water
is a soft boundary which affects the load on the Virtual Memory system. The value is rounded up to the next page boundary. The smaller the value, the smaller the number of pages actually used while sending "normal, small" X messages. Large messages can still be sent at high efficiency. In a memory-poor system making this small may be an advantage, but if sufficient memory is available, the value should be near the default.

The default value for high_water is 90000 or, if region_size is given, 1/8 of the region size (which is appropriate in memory-poor systems), with a minimum of 4096. If high_water is specified (and if region_size is specified, high_water usually should be also) it must be less than the region_size.

buffer_size
is the size used for the "small" requests that X normally generates protocol for. It is extremely unlikely that this will need tuning. It is not rounded. It must be at least 4096, but defaults to the same as the high_water size (if the option is used). Space is left for a control region if necessary.
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.


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

(home) 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 (16x2) 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.

(home) 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.

(home) 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.

(home) 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.

(home) 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).

(home) 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.
Examples of Relevant Graphics Devices:
CRX-24[Z], CRX-48Z
HP VISUALIZE-EG
HCRX-8[Z], HCRX-24[Z]
HP VISUALIZE-8, HP VISUALIZE-24, and HP VISUALIZE-48[XP]
HP VISUALIZE-FX2, HP VISUALIZE-FX4, and HP VISUALIZE-FX6
X*screens File Screen Option To Use:
CountTransparentInOverlayVisual

(home) 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).
Examples of Relevant Graphics Device:
HP VISUALIZE-EG
HCRX-8[Z]
HP VISUALIZE-8
X*screens File Screen Option To Use:
EnableOverlayTransparency

(home) 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.

Examples of Relevant Graphics Device:
Integrated Color Graphics, Color Graphics cards, Internal Color Graphics
X*screens File Screen Option To Use:
3BitCenterColor

(home) 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.

X*screens File Screen Option To Use:
ImageTextViaBitMap

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:
PersonalVRX, TurboVRX
Freedom Series(tm) Graphics (S3150, S3250 and S3400)

(home) 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

(home) 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):

(home) Supported X Configurations

(home) Multi-Display Support

The following definitions are included to reduce confusion between the terms "multi-display," "multi-screen," "multi-seat," and "single logical screen."
Multi-Display
A configuration with multiple graphics devices used concurrently. Any multi-screen, multi-seat, or single logical screen configuration is referred to as a multi-display configuration.
Multi-Screen
A configuration in which a single X server with a mouse and keyboard drives multiple graphics devices (where each display is a different X Screen) concurrently while only allowing the cursor, not windows, to be moved between displays.

Multi-Seat
A configuration with multiple instantiations of the X server, each with its own mouse, keyboard, and display(s). Multi-seat is not supported in any HP-UX 10.* release.

Single Logical Screen
A configuration in which a single X server with a single mouse and keyboard drives multiple homogeneous graphics devices concurrently while allowing the displays to emulate a large single screen. This differs from a multi-screen environment by allowing windows to be moved and displayed across displays. See the section in this document on Single Logical Screen.

Note that different monitor resolutions are not supported with the multi-display configurations unless stated otherwise in the table below.

(home) Multi-Screen Support

The list of supported multi-display configurations is rather large, and it changes whenever a new graphics device is introduced. Thus, if you are considering a Single Logical Screen or any other multi-display configuration, we recommend consulting your HP Sales Representative and inquiring whether the configuration you have in mind is indeed supported.

There are general guidelines, however. For example:

(home) Single Logical Screen (SLS)

SLS is a mechanism for treating homogeneous multi-display configurations as a single "logical" screen. This allows the moving/spanning of windows across multiple physical monitors. The word "homogeneous" is included because SLS only works if the graphics devices included in the SLS Configuration are of the same type. Note that on-board and "card" versions of the same device can be considered identical; for example, you could use an on-board HP VISUALIZE-EG graphics device and an HP VISUALIZE-EG graphics card, and still consider them identical devices, thus permitting a 1x2 SLS or a 2x1 SLS.

SLS is enabled by using SAM (the System Administration Manager tool, /usr/sbin/sam). To enable an SLS configuration, start SAM, and follow the instructions below:

  1. Double-click on the "X Server Configuration" button. A window entitled "Graphics" appears, containing an icon for every graphics device on your system.
  2. Select the devices you want to combine into an SLS (click the mouse on the first device, and [Ctrl]-click on the others). At this point, all the devices you want to combine into an SLS configuration should be highlighted.
  3. From the "Actions" menu, choose the menu item "Modify Multi-Screen Layout". A dialog box appears, allowing you to specify exactly how you want your SLS configuration to be.

Note that if your machine has only one graphics device, the "Modify Multi-Screen Layout" menu option does not even appear, since multiple devices cannot occur in a single-device context.

Note also that DHA (Direct Hardware Access) is not supported in a window that spans multiple screens. This means, for example, that while graphics is supported to a window spanning two or more screens, accelerated graphics is not. "Spanning," in this context, includes a window that is two or more screens in size, as well as a window that is partially on one screen and partially on another (even though it would fit on a single screen if it were moved).

SLS can also be enabled via the /etc/X11/X*screens file via the syntax:

    SingleLogicalScreen n m
        /dev/crt0 ... /dev/crtk
where:
n = the number of "rows" in the physical configuration,
m = the number of "columns" in the physical configuration,
and the product of nxm is less than or equal to four.
For example, to create a logical screen that is one monitor tall by two monitors wide, the following syntax would be used:
    SingleLogicalScreen 1 2
        /dev/crt0 /dev/crt1
Whereas for a logical screen that is two monitors tall by one monitor wide, the syntax is:
    SingleLogicalScreen 2 1
        /dev/crt0 /dev/crt1

(home) 3D Acceleration and Single Logical Screen

Currently, SLS does not take advantage of 3D acceleration (e.g. CRX-24Z). 3D applications (from any supported HP 3D API) will continue to run with SLS; However, 3D performance with SLS will be much slower than it is without SLS.

(home) HP VUE/CDE and Single Logical Screen

Please note that HP VUE/CDE has not been modified to take advantage of the Single Logical Screen capability. When presenting information on your display, HP VUE may split a window across physical screens. Examples include: This behavior is the result of HP VUE's naive assumption that it is running against one large screen; it centers these windows accordingly.

If you are using the default HP VUE key bindings, you can easily reposition the Front Panel so that it is completely contained within one physical screen:

  1. With the input focus on the Front Panel, press [Alt][Spacebar] (on older keyboards, use [Extend char][Spacebar]).
  2. With the Front Panel menu posted and the "Move" menu item selected, press [Enter] (on older keyboards, [Return]) to start the move.
  3. Use the mouse or the arrow keys to reposition the Front Panel to the desired location.
  4. Press [Enter] (or [Return]) to complete the move. You may instead press [ESC] to cancel the move.
Afterwards, this setting will be remembered and restored at your next login. If you have previously set a Home session, you will need to re-set the Home session in the Style Manager to register the new Front Panel position.

Note that there is no mechanism in HP VUE for repositioning the login screen, window move/resize boxes, or the screen lock dialog.

(home) Integrated Color Graphics Device-Dependent Information

This sections includes information on Integrated Color Graphics and Color Graphics cards.

(home) Supported Visuals

For color displays: For grayscale displays, only one visual is supported:

(home) Supported Screen Options

The following Screen Options are supported:

(home) Colormaps and Colormap Management

Color Graphics devices have two hardware colormaps (color lookup tables), each with 256 entries. The X server controls the allocation and contents of these hardware colormaps.

(home) Default Colormap Management Scheme

Many applications use the default X11 colormap. A technicolor effect in the windows using the default colormap occurs when a non-default colormap is downloaded in the hardware colormap that had previously contained the default colormap.

Because so many applications use the default X11 colormap--including the window manager--and because Color Graphics devices have two hardware colormaps, the default behavior on this device is to dedicate one hardware colormap to always hold the default X11 colormap. The second hardware colormap is available to applications that use colormaps other than the default.

The default behavior can cause technicolor if two or more applications are using different, non-default colormaps. For example, Application A uses the default X11 colormap, Application B uses a different colormap, and Application C uses a third colormap. If applications A, B, and C are all executed simultaneously on a Model 712, application A would look correct. Either application B or C would have a technicolor effect--the application whose colormap was last downloaded in the hardware colormap would look correct.

(home) Accessing HP Color Recovery Technology via Xlib

Color Recovery is a technique to generate a better picture by attempting to eliminate the graininess caused by dithering. 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. At server startup (if Color Recovery is not disabled in the X*screens file), the following properties are defined and placed on the root window: These properties are of type RGB_COLOR_MAP and carry pointers to structures of type XStandardColormap. They may be interrogated with calls to XGetRGBColormaps. The colormaps in the _HP_RGB_SMOOTH_TRUE_MAP and _HP_RGB_SMOOTH_PSEUDO_MAP structures identify colormaps which are created at server startup and are for use with the TrueColor and PseudoColor visuals, respectively. They are both initialized to contain the 3:3:2 ramp of 8-bit TrueColor. Neither of these colormaps can be modified as they are read-only. The property _HP_RGB_SMOOTH_MAP_LIST is a list of colormaps that are associated with all of the root window's visual IDs that support Color Recovery. When the XGetRGBColormaps routine searches this list for a colormap with a visual ID that matches the visual ID that your window is using and it finds one, your application knows that your visual supports Color Recovery, and uses that colormap for any Color Recovery window in your window's visual.

Note that the algorithm used for the Color Graphics device is slightly different from that used for the HCRX family of devices. If you do not wish for your application to have to do device-specific checks, HP recommends that you use the HCRX encoding algorithm for Color Recovery regardless of the device on which your application is executing. The results on the Color Graphics device will not be optimal, but will generally still be much better than a standard dither. If you are willing to do device-specific checks, the existence of either the _HP_RGB_SMOOTH_TRUE_MAP or _HP_RGB_SMOOTH_PSEUDO_MAP property will indicate the device is Color Graphics.

Color Recovery uses all 256 entries of one of the available colormaps. The color visual used by Color Recovery emulates the 24-bit TrueColor visual; thus, the colors red, green, and blue are typically declared as integers in the range from 0 to 255. Note that each window that uses Color Recovery will have the same colormap contents.

For Color Recovery to produce the best results, the emulated 24-bit TrueColor data is dithered as explained below.

A pixel to be dithered is sent to the routine provided in this example. Note that the values of the variables RedValue, GreenValue, and BlueValue are generated by an application. In this example, the color values are assumed to be in the range 0..255.

The given routine receives the color values and the X and Y window address (Xp and Yp) of the pixel. The X and Y address is used to access the dither tables. The values from the dither tables are added to the color values. After the dither addition, the resultant color values are quantized to three bits of red and green and two bits of blue. The quantized results are packed into an 8-bit unsigned char and then stored in the frame buffer. In the process of sending the contents of the frame buffer to the CRT, a special section in the hardware then converts the frame buffer's 8-bit data into 24-bit TrueColor data for display.

Here is a routine that can be used to dither the 24-bit TrueColor data.

unsigned char dither_pixel_for_CR(RedValue,GreenValue,BlueValue,Xp,Yp) int RedValue, GreenValue, BlueValue, Xp, Yp; { static short dither_red[2][16] = { {-16, 4, -1, 11,-14, 6, -3, 9,-15, 5, -2, 10,-13, 7, -4, 8}, { 15, -5, 0,-12, 13, -7, 2,-10, 14, -6, 1,-11, 12, -8, 3, -9}}; static short dither_green[2][16] = { { 11,-15, 7, -3, 8,-14, 4, -2, 10,-16, 6, -4, 9,-13, 5, -1}, {-12, 14, -8, 2, -9, 13, -5, 1,-11, 15, -7, 3,-10, 12, -6, 0}}; static short dither_blue[2][16] = { { -3, 9,-13, 7, -1, 11,-15, 5, -4, 8,-14, 6, -2, 10,-16, 4}, { 2,-10, 12, -8, 0,-12, 14, -6, 3, -9, 13, -7, 1,-11, 15, -5} }; int red, green, blue; int x_dither_table, y_dither_table; unsigned char pixel; /* Determine the dither table entries to use based on the pixel address */ x_dither_table = Xp % 16; /* X Pixel Address MOD 16 */ y_dither_table = Yp % 2; /* Y Pixel Address MOD 2 */ /* Start with the initial values as supplied by the calling routine */ red = RedValue; green = GreenValue; blue = BlueValue; /* Generate the red dither value */ red += dither_red[y_dither_table][x_dither_table]; /* Check for overflow or underflow on red value */ if (red > 0xff) red = 0xff; if (red < 0x00) red = 0x00; /* Generate the green dither value */ green += dither_green[y_dither_table][x_dither_table]; /* Check for overflow or underflow on green value */ if (green > 0xff) green = 0xff; if (green < 0x00) green = 0x00; /* Generate the blue dither value */ blue += (dither_blue[y_dither_table][x_dither_table]<<1); /* Check for overflow or underflow on blue value */ if (blue > 0xff) blue = 0xff; if (blue < 0x00) blue = 0x00; /* Generate the pixel value by "or"ing the values together */ pixel = ((red & 0xE0) | ((green & 0xE0) >> 3) | ((blue & 0xC0) >> 6)); return(pixel); }

(home) Internal Color Graphics, Internal Grayscale Graphics, CRX, GRX, and Dual-CRX Device-Dependent Information

(home) Supported Visuals

Only one visual is supported.

For color displays:

For grayscale displays: The "layer" and "transparent" default visual options are not supported.

(home) Supported Screen Options

The following Screen Options are supported:

(home) CRX-24[Z] Device-Dependent Information

(home) Supported Visuals

The following visuals are supported:

(home) Supported Screen Options

The following Screen Options are supported:

(home) CRX-24[Z] Transparent Overlay Visuals

The default number of colormap entries in the overlay visual for the CRX-24[Z] is 255. Entry 255 is excluded because its value is hard-coded to transparent (that is, show the image planes).

This may have the following two consequences for X11 applications running in the overlay planes (the default visual):

This default behavior can be changed by setting the CountTransparentInOverlayVisual screen option.

When this option is enabled, the X server does the following:

(home) CRX-48Z Device-Dependent Information

(home) Supported Visuals

The following visuals are supported:

(home) Supported Screen Options

The following Screen Options are supported:

(home) CRX-48Z Transparent Overlay Visuals

The default number of colormap entries in the overlay visual for the CRX-48Z is 255. Entry 255 is excluded because its value is hard-coded to transparent (that is, show the image planes).

This may have the following two consequences for X11 applications running in the overlay planes (the default visual):

This default behavior can be changed by setting the CountTransparentInOverlayVisual screen option.

When this option is enabled, the X server does the following:

(home) HCRX and HP VISUALIZE Device-Dependent Information

This section includes information on the HCRX-8[Z], HCRX-24[Z], HP VISUALIZE-EG, HP VISUALIZE-8, HP VISUALIZE-24, and HP VISUALIZE-48[XP] graphics devices.

The HCRX-8[Z] is a one-board device (two, with the optional accelerator) that has eight overlay planes, two banks of 8 image planes, and 4 hardware colormaps. This device provides a superset of functionality in the CRX.

The HCRX-24[Z] is a one board device (two, with the optional accelerator) that has eight overlay planes, two banks of 12 image planes, and 4 hardware colormaps. This device provides a superset of functionality in the CRX-24[Z].

The HP VISUALIZE-EG is either an unaccelerated built-in graphics device or a single board unaccelerated graphics device (not counting the optional memory daughter card in either case). This device provides compatible functionality with the Integrated Color Graphics device when in 8 plane mode and has functionality compatible with the HCRX-8 device when in double-buffer mode. See below for a description of these modes. For shorthand notation, from this point on in the document, HP VISUALIZE-EG will refer to either mode, HP VISUALIZE-EG(8) will refer to 8 plane mode only and HP [Dual] VISUALIZE-EG will refer to double-buffer mode only.

The HP VISUALIZE-8 is a two board accelerated device that has eight overlay planes, two banks of 8 image planes, and 4 hardware colormaps. This device provides a superset of functionality in the CRX.

The HP VISUALIZE-24 is a two board accelerated device that has eight overlay planes, two banks of 12 image planes, and 4 hardware colormaps. This device provides a superset of functionality in the CRX-24[Z].

The HP VISUALIZE-48[XP] is a two-board accelerated device that fills two slots. If you add either the optional texture-mapping memory card or the optional video-out card, it becomes a three-board set that fills three slots. Add both optional cards, and it becomes a four-board set, but it still fills only three slots. In any case, it has eight overlay planes, two banks of 24 image planes, and six hardware colormaps. This device provides a superset of functionality in the CRX-48Z. The hardware support for accelerating 2D Xlib primitives is similar to that in the other HCRX devices. The hardware for accelerating 3D geometry, lighting, and shading, is new.

(home) Supported Visuals

The following visuals are supported on the HP VISUALIZE-EG(8): The following visuals are supported on the HCRX-8[Z], HP [Dual] VISUALIZE-EG and HP VISUALIZE-8:

Note: The two overlay visuals are mutually exclusive, based on the presence of the EnableOverlayTransparency screen option (i.e., if the EnableOverlayTransparency screen option is set, then the visual that supports transparency is available, otherwise the visual which does not support transparency is available).


The following visuals are supported on the HCRX-24[Z] and HP VISUALIZE-24: The following visuals are supported on the HP VISUALIZE-48[XP]:

(home) Supported Screen Options

The following Screen Options are supported:

(home) HP VISUALIZE-EG Modes

The following modes are supported: The modes are set from the Boot-Admin at bootup time by selecting from the menu of options a configuration that supports double-buffer or not. From that point on (without rebooting) the server will use the selected mode.

Eight-plane mode is compatible with the Integrated Color Graphics device. It has eight image planes and uses only software double-buffering.

Double-Buffer mode is compatible with the HCRX-8 device. This mode requires an optional memory daughter card. If the daughter card is installed, selecting this mode will result in eight overlay planes and 16 image planes (the same as HCRX-8 and HP VISUALIZE-8 devices). Double-Buffer mode allows the use of hardware double-buffering.

(home) HCRX Configuration Hints

(home) HCRX-8[Z], HP [Dual] VISUALIZE-EG and HP VISUALIZE-8 Visuals and Double-Buffer Support

The eight-plane HCRX-8[Z], HP [Dual] VISUALIZE-EG and HP VISUALIZE-8 are the first members of the Series 700 graphics family whose overlay planes and image planes are both depth 8.

(home) Implications and Suggestions for HCRX-8[Z], HP [Dual] VISUALIZE-EG and HP VISUALIZE-8

The default colormap cannot be used with a window in a non-default visual, even one of the same depth as the default visual.

Before trying to use the default colormap in a depth-8 window, verify that the window is in the default visual. If the window is not in the default visual, create a colormap in that visual. This process of creating a non-default colormap is the same as the one used to create windows in depth-12 or depth-24 visuals.

If you have an application that assumes that the default colormap can be used with any depth-8 window (even one in an image-plane visual) specify an image-plane visual as the default.

Unlike the CRX, the HCRX-8[Z]'s default visual the HP [Dual] VISUALIZE-EG's default visual and the HP VISUALIZE-8's default visual do not have fast hardware double-buffering (but the image planes do).

To obtain hardware double-buffering, find a visual in the image planes. The best method is to find all the depth-8 PseudoColor visuals returned by XGetVisualInfo and then eliminate the visuals that are reported in the SERVER_OVERLAY_VISUALS property (discussed below).

If you have an application that assumes the default visual has fast double-buffering, specify an image plane visual as the default.

(home) HCRX Overlay Visuals and Overlay Transparency

As on the CRX-24[Z] and CRX-48Z, a property on the root window, SERVER_OVERLAY_VISUALS, is used to describe the visuals that are in the overlay planes.

(home) Overlay Transparency on the HCRX-8[Z], HP [Dual] VISUALIZE-EG and HP VISUALIZE-8

The HCRX-8[Z], HP [Dual] VISUALIZE-EG and HP VISUALIZE-8 each have one visual in the overlay planes (depth-8 PseudoColor). By default, this overlay visual has no transparent index available to applications for rendering transparency. This means the overlay windows with "floating text" are not supported in the typical X server operation on the HCRX-8[Z], HP [Dual] VISUALIZE-EG or HP VISUALIZE-8.

For applications that require transparent overlay windows on the HCRX-8[Z], HP VISUALIZE-EG(D) or HP VISUALIZE-8, an optional X server mode is available to allow for overlay transparency, but it is restrictive. In this optional mode, overlay colormaps provide a single entry that can be used to render transparency. Only one hardware colormap is available in the overlays (instead of two) and only one hardware colormap is available in the image planes (instead of two).

To activate this optional X server mode to enable transparency, set the EnableOverlayTransparency screen option. You will need to restart the X server for the option to take effect.

With this mode enabled, colormaps created in the default visual have 255 entries; entry 256 is reserved for transparency. As on the CRX-24[Z] and CRX-48Z, the screen option CountTransparentInOverlayVisual can be used to include the transparent index in the colormap size (256 entries instead of 255).

Programmers' Note
If transparency is not enabled, there are only 252 colors available. Entries 252-255 are not writable, and should not be used; there are only 252 colormap entries available, even though the server states that there are 256.

(home) Overlay Transparency on the HCRX-24[Z], HP VISUALIZE-24, and HP VISUALIZE-48[XP]

The HCRX-24[Z], HP VISUALIZE-24, and HP VISUALIZE-48[XP] have two visuals in the overlay planes, both depth-8 PseudoColor.

The default overlay visual has 256 entries per colormap and no transparency.

The second overlay visual has 255 entries per colormap and supports transparency in the same way as the CRX-24[Z]. As on the CRX-24[Z] and CRX-48Z, the screen option EnableOverlayTransparency can be used to include the transparent index in the colormap size (256 entries instead of 255).

To allow applications to determine which visuals are in the overlay planes, both overlay visuals are listed in the SERVER_OVERLAY_VISUALS property attached to the root window. The default overlay visual has a transparent type of 0 (None) while the transparent overlay visual has a transparent type of 1 (TransparentPixel).

If you need an overlay colormap that supports transparency, create the colormap using the visual that has transparency in its SERVER_OVERLAY_VISUALS property. To look at the contents of this property, you would use code similar to the following:

{ typedef struct { VisualID overlayVisualID; Card32 transparentType;/* None, TransparentPixel, TransparentMask */ Card32 value; /* Either pixel value or pixel mask */ Card32 layer; } OverlayVisualPropertyRec; OverlayVisualPropertyRec *pOverlayVisuals, *pOVis; XVisualInfo getVis; XVisualInfo *pVisuals; Atom overlayVisualsAtom, actualType; ... /* Get the visuals for this screen and allocate. */ getVis.screen = screen; pVisuals = XGetVisualInfo(display, VisualScreenMask, &getVis, &nVisuals); pOverlayVisuals = (OverlayVisualPropertyRec *) malloc ( (size_t)nVisuals * sizeof(OverlayVisualPropertyRec) ); /* Get the overlay visual information for this screen. Obtain * this information from the SERVER_OVERLAY_VISUALS property. */ overlayVisualsAtom = XInternAtom(display, "SERVER_OVERLAY_VISUALS", True); if (overlayVisualsAtom != None) { /* Since the Atom exists, request the property's contents. */ bytesAfter = 0; numLongs = ( nVisuals * sizeof(OverlayVisualPropertyRec) + 3 ) / 4; XGetWindowProperty(display, RootWindow(display, screen), overlayVisualsAtom, 0, numLongs, False, AnyPropertyType, &actualType, &actualFormat, &numLongs, &bytesAfter, &pOverlayVisuals); if ( bytesAfter != 0 ) {/* Serious Failure Here */} ; /* Loop through the pOverlayVisuals array. */ ... nOVisuals = numLongs/sizeof(OverlayVisualPropertyRec); pOVis = pOverlayVisuals; while (--nOVisuals >= 0) { if ( pOVis->transparentType == TransparentPixel ) {/* Found a transparent overlay visual, set ident. aside. */}; pOVis++; } XFree(pOverlayVisuals); /* There might be some additional checking of the found transparent overlay visuals wanted; e.g., for depth. */ } XFree(pVisuals); } This program fragment is not complete; its main purpose is to give the idea of how to find an overlay visual having transparency.

(home) HCRX Colormaps

The following information discusses the number of supported colormaps for the HCRX configurations.

(home) HP VISUALIZE-EG(8): 8 Image planes

The image planes contain the default colormap permanently installed in the hardware plus one other hardware colormap available to applications. No issues involving transparency exist because of the lack of Overlay planes.

(home) HCRX-8[Z], HP [Dual] VISUALIZE-EG and HP VISUALIZE-8: Eight Overlay Planes and Two Depth-8 Banks of Image Planes

When the default visual is in the overlay planes (default location) and the screen option EnableOverlayTransparency is not set, the overlay planes contain the default colormap permanently installed in the hardware, plus one other hardware colormap available to applications. The image planes contain two hardware colormaps each usable by applications.

When the default visual is in the image planes and the screen option EnableOverlayTransparency is not set, the overlay planes contain a single hardware colormap available to applications, plus a colormap reserved by the server (i.e., unavailable to applications) to guarantee the existence of transparency, and the image planes contain the default colormap permanently installed into the hardware, plus one other hardware colormap available to applications.

When the screen option EnableOverlayTransparency is set, both the overlay planes and the image planes have access to one hardware colormap. The default colormap is not permanently installed in the hardware and is in the overlay planes by default, but the Default Visual can be located in the image planes as described in a previous section.

(home) HCRX-24[Z] and HP VISUALIZE-24: Eight Overlay Planes and 24 Image Planes

The overlay planes contain the default colormap permanently installed in the hardware, plus one other hardware colormap available to applications. The image planes contain two hardware colormaps, each usable by applications.

Although two hardware colormaps are available to applications in the image planes, a hardware restriction allows only one depth-12 or depth-24 colormap to be installed at any given time. Therefore, if two applications are run simultaneously and use different depth-12 or depth-24 colormaps, the application that has the colormap focus looks correct and the other is technicolored.

(home) HP VISUALIZE-48[XP]: Eight Overlay Planes and 48 Image Planes

The overlay planes contain the default colormap permanently installed in the hardware, plus one other hardware colormap available to applications. The image planes contain four hardware colormaps, each usable by applications.

The four hardware colormaps in the image planes can be treated as depth-8 or depth-24 colormaps. There are no restrictions on the types of colormaps that can be installed in the hardware at any given time. All four colormaps can be used with any visual class.

(home) Accessing HP Color Recovery Technology via Xlib

Color Recovery is a technique to generate a better picture by attempting to eliminate the graininess caused by dithering. 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. At server startup (if Color Recovery is not disabled in the X*screens file), the _HP_RGB_SMOOTH_MAP_LIST property is defined and placed on the root window.

The above property is of type RGB_COLOR_MAP and carries pointers to structures of type XStandardColormap. It may be interrogated with calls to XGetRGBColormaps. The property _HP_RGB_SMOOTH_MAP_LIST is a list of colormaps that are associated with window visual IDs that support Color Recovery. When the XGetRGBColormaps routine searches this list for a colormap with a visual ID that matches your window's visual ID and it finds one, your application knows that your visual supports Color Recovery, and uses that colormap for any Color Recovery window in your window's visual.

Color Recovery uses all 256 entries of one of the available colormaps. The color visual used by Color Recovery emulates the 24-bit TrueColor visual, thus, the colors red, green, and blue are typically declared as integers in the range from 0 to 255. Note that each window that uses Color Recovery will have the same colormap contents.

For Color Recovery to produce the best results, the emulated 24-bit TrueColor data is dithered as explained below.

A pixel to be dithered is sent to the routine provided in this example. Note that the values of the variables RedValue, GreenValue, and BlueValue are generated by an application. In this example, the color values are assumed to be in the range 0..255.

The given routine receives the color values and the X and Y window address (Xp and Yp) of the pixel. The X and Y address is used to access the dither tables. The values from the dither tables are added to the color values. After the dither addition, the resultant color values are quantized to three bits of red and green and two bits of blue. The quantized results are packed into an 8-bit unsigned char and then stored in the frame buffer. In the process of sending the contents of the frame buffer to the CRT, a special section in the hardware then converts the frame buffer's 8-bit data into a 24-bit TrueColor data for display.

Here is a routine that can be used to dither the 24-bit TrueColor data.

unsigned char dither_pixel_for_CR(RedValue,GreenValue,BlueValue,Xp,Yp) int RedValue,GreenValueBlueValue,Xp,Yp; { static short dither_red[2][16] = { {-16, 4, -1, 11,-14, 6, -3, 9,-15, 5, -2, 10,-13, 7, -4, 8}, { 15, -5, 0,-12, 13, -7, 2,-10, 14, -6, 1,-11, 12, -8, 3, -9}}; static short dither_green[2][16] = { { 11,-15, 7, -3, 8,-14, 4, -2, 10,-16, 6, -4, 9,-13, 5, -1}, {-12, 14, -8, 2, -9, 13, -5, 1,-11, 15, -7, 3,-10, 12, -6, 0}}; static short dither_blue[2][16] = { { -3, 9,-13, 7, -1, 11,-15, 5, -4, 8,-14, 6, -2, 10,-16, 4}, { 2,-10, 12, -8, 0,-12, 14, -6, 3, -9, 13, -7, 1,-11, 15, -5}}; int red, green, blue; int x_dither_table, y_dither_table; unsigned char pixel; /* Determine the dither table entries to use based on the pixel address */ x_dither_table = Xp % 16; /* X Pixel Address MOD 16 */ y_dither_table = Yp % 2; /* Y Pixel Address MOD 2 */ /* Start with the initial values as supplied by the calling routine */ red = RedValue; green = GreenValue; blue = BlueValue; /* Generate the red dither value */ if (red >= 48) /* 48 is a constant required by this routine */ red=red-16; else red=red/2+8; red += dither_red[y_dither_table][x_dither_table]; /* Check for overflow or underflow on red value */ if (red > 0xff) red = 0xff; if (red < 0x00) red = 0x00; /* Generate the green dither value */ if (green >= 48) /* 48 is a constant required by this routine */ green=green-16; else green=green/2+8; green += dither_green[y_dither_table][x_dither_table]; /* Check for overflow or underflow on green value */ if (green > 0xff) green = 0xff; if (green < 0x00) green = 0x00; /* Generate the blue dither value */ if (blue >= 112) /* 112 is a constant required by this routine */ blue=blue-32; else blue=blue/2+24; blue += (dither_blue[y_dither_table][x_dither_table]<<1); /* Check for overflow or underflow on blue value */ if (blue > 0xff) blue = 0xff; if (blue < 0x00) blue = 0x00; pixel = ((red & 0xE0) | ((green & 0xE0) >> 3) | ((blue & 0xC0) >> 6)); return(pixel); }


[Prev] [Index] [Next]