| United States-English |
|
|
|
![]() |
HP-UX Starbase Device Drivers Manual - Vol1: HP 9000 Series 700 Computers > Chapter 3 The HCRX Family of Device DriversX Windows |
|
To reduce the complexity of multiple X server modes, the hphcrx drivers for X and Starbase only support one X server mode for each device. Several other key features have also been designed to improve the overall usability of the devices in the X11 windows environment and to reduce the interactions between the X11 user interface and graphics library APIs that provide direct hardware access (DHA) such as Starbase. The HCRX family of graphics devices support double buffering in images planes on a per-window basis. HCRX-8 and HCRX-8Z support 8/8 planes double-buffered for each of the Starbase color map modes (CMAP_NORMAL, CMAP_MONOTONIC, CMAP_FULL). In the image planes, the HCRX-24 and HCRX-24Z support the above mentioned modes and also 12/12 planes double-buffered in the CMAP_FULL color map mode. Any X11 library drawing routines will render to the currently visible buffer of a window that has double-buffering enabled. The HCRX family of graphics devices has two hardware color maps in the overlay planes and two hardware color maps in the image planes. Using the default X server mode of the HCRX family of graphics devices, if you query the X server for the number of entries in the default overlay visual's color map, the server will reply that there are 256 entries available. Although all 256 entries are available for use by an application, the last four entries (indexes 252 through 255) are not writable as they are allocated by the X server (this is only true for the HCRX-8 and HCRX-8Z graphics devices). The X color model defines read/write restrictions both on color maps and on individual entries in color maps. As of HP-UX 9.05, Starbase no longer overwrites read-only color maps or color map entries as defined in the X color model. Starbase will generate a warning message if the application attempts to overwrite read-only color map entries. Attempts to write to color map entries in read-only color maps (color maps in StaticGray, StaticColor or TrueColor visuals) are silently ignored. For more information on this subject, read the section "Starbase Color Maps and X11 Read/Write Restrictions" in Chapter 1.
The HCRX family of graphics devices support HP Color Recovery for shaded areas. When an 8-bit window is used, HP Color Recovery will generate a better picture by attempting to eliminate the graininess caused by dithering. Color recovery is available on all windows on the HCRX-8 and HCRX-8Z, but only in 8-bit windows on the HCRX-24 and HCRX-24Z. For more information about HP Color Recovery, read the section "HP Color Recovery" found in this chapter. The Starbase and HP-PHIGS graphics libraries provide programmers who use these APIs with transparent access to the HP Color Recovery capability of the HCRX family of graphics devices. If you are producing graphics using Xlib calls, then your application must perform some of the necessary processing. At server start-up, there is one property that is defined and placed on the root window if the HP_DISABLE_COLOR_RECOVERY environment variable has not been exported. This property is:
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 color maps that are associated with window visual IDs that support HP Color Recovery. When the XGetRGBColormaps routine searches throughout this list for a color map with a visual ID that matches your window's visual ID and it finds one, your application knows that your visual supports HP Color Recovery, and uses that color map for any HP Color Recovery window. HP Color Recovery uses all 256 entries of one of the available color maps. The color visual used by HP 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 HP Color Recovery will use the same color map. For HP 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
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 3 bits of red and green and 2 bits of blue. The quantized results are packed into an 8-bit unsigned char and then stored in the frame buffer. As the contents of the frame buffer are scanned to the CRT, a special section in the HCRX hardware then converts the 8-bit data stored in the frame buffer into a 24-bit TrueColor image for display. Here is a routine that can be used to dither the 24-bit TrueColor data.
The HCRX family of graphics devices all support backing store (also known as "retained raster"). The backing store feature allows a window being rendered to by a DHA client to be "backed-up" to a virtual frame buffer whenever any portion of the window is obscured by another window. In this case, the application is not required to catch "expose events" from X11 and redraw the picture when occlusion occurs. In fact, no "expose events" will be generated if backing store is enabled. Thus, when a window is placed on top of another window containing a complete image, the window system will save the contents of the latter window before displaying the obscuring window. Then, when the obscuring window is removed, the earlier contents of the occluded area plus any new rendering that has occurred in the occluded area during the cover-up will be restored. Since rendering to the virtual frame buffer is not as fast as rendering to the actual frame buffer in the occluded area, the performance will suffer, but only while the window is occluded. In general, those Starbase operations that draw to the display are also supported when drawing to backing store. The exceptions to this are:
If these limitations on backing store support prove troublesome in your application, do not use backing store. Instead, detect window exposure events and repaint the window when a previously obscured portion of a window is made visible. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||