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-UX Starbase Device Drivers Manual - Vol1: HP 9000 Series 700 Computers > Chapter 2 HP VMX Device Driver

VM Rendering Utilities

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Index

It is important to note that this section covers VM Rendering Utilities and not HP VMX driver functionality.

As mentioned in the section "HP VMX Device Driver, VM Rendering Utilities, and Overlay Planes" Starbase implements a set of VM Rendering Utilities which rely on a portion of the HP VMX functionality.

Recall that HP VMX performs two basic functions:

  • Renders Starbase graphics into a virtual memory frame buffer.

  • Displays this VM frame buffer in the targeted X11 window.

The set of VM rendering utilities exercise only the first of these two HP VMX functions — the rendering of Starbase graphics into a virtual memory frame buffer. The method of display is not handled by HP VMX, but by the methods described in the subsequent sections. This section takes a look at the VM rendering utilities and briefly explains their implementation.

Note, while these utilities are largely internal implementation details, they are worth discussion here so that you recognize the similarities between their implementation and the use of HP VMX as a device driver.

VM Double-Buffering on 8-plane devices

Virtual Memory Double-Buffering

4/4 double-buffering limitations

Where double-buffering on Series 700 models with integrated and internal color graphics is possible, it is limited. As 8-plane devices, these models only allow 4/4 double-buffering. You are limited to 16 colors as rendering in this mode uses four planes at a time. Also, X11 does not support 4/4 double-buffering, so where your graphics window double-buffers as expected, the rest of your windows may flash. Note that 4/4 double-buffering is not supported with CMAP_FULL mode.

8/8 double-buffering enhanced performance

Virtual memory (VM) 8/8 double-buffering is supported by setting the HP_VM_DOUBLE_BUFFER environment variable to TRUE. (Note that the environment variable HP_VM_DOUBLE_BUFFER applies to Internal Color and Integrated Graphics Workstations). This functionality allows you to double-buffer in 8 planes per buffer, giving you access to 256 colors. It is also supported by X11 so window flashing is not a problem.

Here's how it works:

The virtual memory buffer is allocated by the Starbase graphics library to mirror the window. The VM rendering capabilities of HP VMX are used to render the Starbase graphics images into the allocated virtual memory buffer. The Starbase graphics library then copies the VM buffer (containing the Starbase graphics output) to the display frame buffer at dbuffer_switch time.

Be aware of tradeoffs

VM double-buffering is not appropriate for all applications. You should first evaluate the performance of your application against the following tradeoffs:

  1. Speed — VM rendering uses only software rendering. As a result, rendering to the VM buffer is somewhat slower for many operations and significantly slower for a few operations such as rendering non-Z-buffered, non-shaded vectors.

  2. More memory — A VM double-buffering application uses more virtual memory in order to allocate the VM buffer. The size of this buffer is proportional to the size of the window when it was gopened for rendering. The buffer size is one byte for each pixel in the window. If the SUPPRESS_CLEAR double-buffering flag is set, then the VM buffer will be double the size of the window. Note that the buffer memory is returned to the system when the application process terminates; it does not stay allocated with the window. (Most applications do not need to change the kernel configuration to use this capability. If your application has problems, you can increase the kernel's maxdsiz parameter using SAM(1)).

  3. SUPPRESS_CLEAR — As of HP-UX 9.05, Starbase VM (virtual memory) double-buffering supports SUPPRESS_CLEAR. If the mode parameter of the double_buffer command is ORed with the SUPPRESS_CLEAR flag, then the buffer that is enabled for writing will not be cleared by subsequent calls to the dbuffer_switch command. Also, multiple Starbase gopen calls to the same VM double-buffered window will use the same VM double-buffer (rather than a new VM double-buffer for each gopen call).

To enable VM double-buffering

There are two ways you can enable VM double-buffering on Internal Color and Integrated Graphics Workstations (only true for these workstations).

  • You need to define the HP_VM_DOUBLE_BUFFER variable in your environment before starting your application. For example, using ksh syntax, execute the following:

    export HP_VM_DOUBLE_BUFFER=TRUE  or
  • The application can define the environment variable itself before gopening the window using the putenv(3c) function.

Once VM double-buffering is enabled as above, the Starbase double_buffer function accepts 8 planes to be specified in the planes' parameter. If VM double-buffering is not enabled, the double_buffer function limits you to 4 planes.

VM Backing Store

The Starbase Graphics Techniques manual gives a good explanation of backing store (also known as "retained raster"). Backing store is memory used to retain graphics data rendered to obscured portions of a window. This memory is allocated by the X server. The VM rendering capabilities of HP VMX are used to render the Starbase graphics images into the allocated backing store memory. The X server is then responsible for copying this backing store memory to the window when the obscured regions are exposed.

NOTE: HP VMX only supports 8-plane rendering, and therefore is only used for backing store of 8-plane image windows on the CRX and HCRX families of device drivers.

Refer to the "Backing Store Operation" section of the Starbase Graphics Techniques manual for more information on backing store.

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