Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
HP PEX Implementation and Programming Supplement: HP9000 Series 700 Color Workstations > Chapter 3 Running HP PEXlib Programs

Operating Methods

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

This section describes differences in how the client application can control the way rendering is performed through the HP PEXlib interface. There are three basic methods that PEXlib can assume: DHA, PEX, or X. You make the selection via the type of X display connection (normally specified with the environment variable DISPLAY) and the environment variable HPPEX_CLIENT_PROTOCOL.

Instructions for setting and controlling these methods using the DISPLAY and HPPEX_CLIENT_PROTOCOL as one of the environment variables are covered in this chapter. (The other environment variables that affect PEXlib behavior are also covered in a later section of this chapter).

In the accompanying table, you see the possible values of the environment variable HPPEX_CLIENT_PROTOCOL against the possible values of the X DISPLAY variable. Each cell in the table shows the order in which PEXlib tries to initialize the client connection based on the two environment variables. The progression is shown by "→".

If the HPPEX_CLIENT_PROTOCOL environment variable is not set, or is set to an unrecognized value, this indicates the client wants PEXlib to select the best possible connection method to the server based on rendering performance and the relation between client and server systems. If a specific connection type is asked for, but the connection cannot be made, PEXlib does not try any other options and initialization fails.

A maximum of 16 display connections per HP-UX process can be initialized for PEXlib at the same time (see PEXInitialize).

Definitions for the terms that appear in the following table are explained here:

Table 3-1 Definitions Used In Table 3-2

local_host:n.n

Indicates the client has connected to a server on the local machine, the same machine the client is running on.

remote_host:n.n

Indicates the client has connected to a server on the remote machine, a machine other than one the client is running on.

default

If HPPEX_CLIENT_PROTOCOL environment variable is not set, or is set to an unrecognized value, this indicates the client wants PEXlib to select the best possible connection method to the server based on rendering performance and the relation between client and server systems.

DHA

Indicates the client will try to connect to the server using DHA (Direct Hardware Access). DHA does maintain a connection to the server, but not for rendering. All PEX rendering is done directly to the hardware, in cooperation with the X server.

PEX

Indicates the client will try to connect to the server using the PEX protocol extension.

X

Indicates the client will try to connect to the server using the X protocol.

 

Table 3-2 Progression of Protocol Selection

HP PEX Client Protocol

X Display Variable

unix:n.n or

remote_host:n.n

local:n.n or

 

shmlink:n.n or

 

local_host:n.n

 

default[1]

DHA→PEX→X→Error

PEX→X→Error

DHA

DHA→Error

Error

PEX

PEX→Error

PEX→Error

X

X→Error

X→Error

[1] If the HPPEX_CLIENT_PROTOCOL environment variable is not set (or is set to an unrecognized value), PEXlib selects the method for best rendering performance.

 

Direct Hardware Access Method (DHA)

The DHA protocol method, a Hewlett-Packard feature, provides the highest graphics performance for local connections, its chief advantage. However, DHA is available only when the client and server are on the same workstation; that is, the client is running on the local server.

Visible Behavioral Differences of DHA Method

A client may want to use DHA method (and will get DHA method by default on a local machine) for performance reasons. However, since DHA method does not generate any PEX protocol requests, some minor behavioral differences may be observed. The differences are listed here along with a brief explanation:

  • Request Sequence Numbers Reported by Errors — Normally, each X/PEX protocol request is tagged with a sequence number when it is sent to the X server. Both the client and the server keep track of these numbers independently. If an error occurs, the client reports an error for the request along with the sequence number of the request.

    In the DHA method, the sequence numbers reported for errors generated by PEX requests are meaningless. In the place of the appropriate sequence number, the application receives a sequence number for the most recent Xlib request, as if no PEX requests were being generated. This is natural because DHA method doesn't generate protocol, but it is a difference the application may see if any errors are generated.

  • Floating Point Exceptions — Clients can receive floating-point exceptions due to bad data (see table "Data Values That Cause Problems," at the end of the chapter) or some divide-by-zero operations when running DHA.

It is often helpful to debug your applications using the DHA Protocol Method, before attempting to run them using the X Protocol Method. This is because errors are asynchronous in the X Protocol Method and because DHA rendering does additional error checking.

PEX Protocol Method

PEX protocol method provides the best performance in distributed graphics environments when a PEX-capable server is available, i.e., when the client and server are on different systems and the remote X server has initialized the PEX extension. In this method, PEX protocol is transmitted over the network to the remote server. Performance is dependent upon factors such as network loading, bandwidth, and the type of network.

There is little that can be assumed about protocol performance when sending PEX protocol to other vendors' PEX servers. Performance issues relating to the network type and total bandwidth apply, but the point-to-point capacities of the various vendors' network interface cards vary. In addition, each particular implementation of the PEX standard will possess its own performance characteristics.

X Protocol Method

This method is provided so that an HP PEXlib client application can run to an X server or X terminal that does not support the PEX extension. This method is characterized by local rendering into virtual memory, followed by XPutImage requests to the server. Since this method also uses the network for protocol transmission, it is subject to the same performance considerations as the PEX Protocol method. This method can be "forced," even if the server does support the PEX extension.

Visible Behavioral Differences of X Protocol Method

All the comments pertaining to the DHA method are also applicable to X Protocol method, plus the following additional differences:

  • PEX Extension Initialization — Normally, a PEX extension is supported by the server and a corresponding structure is created on the client side when the PEX extension is initialized. In X protocol method, either there is no PEX extension on the server, or, the application is forcing rendering using the X protocol even though PEX is supported. The first case is the one that exhibits a difference.

    Since there is no PEX extension on the server, HP PEXlib creates a client-side extension structure anyway in order to function properly. However, the server knows nothing about a PEX client. In essence, the client thinks there is a PEX extension, the server thinks there is not.

    One result of this is that if the client calls XListExtensions or XQueryExtension, the PEX extension will not show up. (For this reason, applications that check PEX support and quit if there is no support in the server cannot use the X protocol method without some changes.) However, the PEXInitialize call will succeed.

    Another result of this is that error reporting and extension-event handling may collide with another valid initialized extension. The client may interpret a PEX error or event to be from another initialized extension. This aliasing behavior will only show up if enough valid extensions are initialized by the client so that the error- and event spaces are filled up — overlapping the PEX "fake" extension.

  • PEX Fonts — The only font directories that are searched are the directories named in the file 〈extensions/fp.PEX[8] on the system where the client is running. All PEX fonts that are needed must be on the client's system.



[8] The actual pathname of this directory depends on the file system structure. See the Graphics Administration Guide for details.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 1996 Hewlett-Packard Development Company, L.P.