Reference Guide > Output Devices and Window Systems > Window System Features
  

Window System Features
PV-WAVE utilizes the native window system by creating and using one or more largely independent windows, each of which can be used for the display of graphics and/or images. One color table is shared among these windows. Up to 32 separate windows can be active at any time. Windows are referenced using their index, an integer value between 0 and 31.
“Dithering” or halftoning techniques are used to display images with multiple shades of gray on monochrome displays—displays that can only display white or black. This topic is discussed in the PV‑WAVE User’s Guide.
Graphic and image output is always directed to the current window. When a window system is selected as the current graphics device, the index number of the current window is found in the !D.Window system variable. This variable equals –1 if no window is open or selected. The WSET procedure is used to change the current window. WSHOW hides or displays a window. WDELETE deletes a window.
The WINDOW procedure creates a new window with a given index. If a window already exists with the same index, it is first deleted. The size, position, title, and number of colors may also be specified. If you access the display before creating the first window, PV‑WAVE automatically creates a window with an index number of 0 and with the default attributes.
How Is Backing Store Handled?
One of the features that distinguishes various window systems is how they handle the issue of backing store. When part of a window that was previously not visible is exposed, there are two basic approaches that a window system can take. Some keep track of the current contents of all windows and automatically repair any damage to their visible regions (retained windows). This saved information is known as the backing store. Others simply report the damage to the program that created the window and leave repairing the visible region to the program (non-retained windows). There are convincing arguments for and against both approaches. It is generally more convenient for PV‑WAVE if the window system handles this problem automatically, but this often comes at a performance penalty. The actual cost of retained windows varies between systems and depends partially on the application.
The X Window and Microsoft Windows systems do not by default keep track of window contents. Therefore, when a window on the display is obscured by another window, the contents of its obscured portion is lost.
 
note
For UNIX users, re-exposing the window causes the X server to fill the missing data with the default background color for that window, and request the application to redraw the missing data. Applications can request a backing store for their windows, but servers are not required to provide it. Most current X servers do not provide backing store, and even those that do cannot necessarily provide it for all requesting windows. Therefore, requesting backing store from the server might help, but there is no certainty.
For Windows users, re-exposing the window causes the Microsoft Windows window manager to fill the missing data with the default background color for that window, and request the application to redraw the missing data.
The window system drivers allow you to control backing store using the Retain keyword to the DEVICE and WINDOW procedures. Using Retain with DEVICE allows you to set the default action for all windows, while using it with WINDOW lets you override the default for the new window. The possible values for this keyword are summarized in the following list, and are described in greater detail following the list.
*0—No backing store.
*1—(The Default) The server or window system is requested to retain the window.
*2—PV‑WAVE should provide a backing pixmap and handle the backing store directly (X Window System only).
0—A value of 0 specifies that no backing store is kept. In this case, exposing a previously obscured window leaves the missing portion of the window blank. Although this behavior can be inconvenient, it usually has the highest performance because there is no need to keep a copy of the window contents.
1—(The Default) Setting the Retain keyword to 1 causes PV‑WAVE to request that a backing store be maintained. If the window system decides to accept the request, it automatically repairs the missing portions when the window is exposed. X Windows may or may not, depending on the capabilities of the server and the resources available to it.
2—Specifies that PV‑WAVE should keep a backing store for the window itself, and repair any window damage when the window system requests it. This option exists mainly for the X Window System. Under X, a pixmap (off-screen display memory) the same size as the window is created at the same time the window is created, and all graphics operations sent to the window are also sent to the pixmap. When the server requests PV‑WAVE to repair freshly exposed windows, this pixmap is used to fill in the missing contents. Pixmaps are a precious resource in the X server, so backing pixmaps should only be requested for windows with contents that must absolutely be preserved.
If the type of backing store to use is not explicitly specified using the Retain keyword, PV‑WAVE assumes Option 1 and requests the window system to keep a backing store.
 
note
For UNIX users, some IBM AIX systems do not have backing store enabled in the X server. For this reason, DEVICE, Retain=2 is set by the Standard Library procedure SETDEMO_RS6000.pro. With backing store enabled, you can achieve increased performance by setting DEVICE, Retain=1. Your system administrator can help you determine whether or not backing store is enabled on your system. To enable backing store, kill your workstation’s X server and restart with:
xinit -- -bs -fn fixed

Version 2017.1
Copyright © 2019, Rogue Wave Software, Inc. All Rights Reserved.