Stacking window manager

A stacking window manager is a window manager that draws all windows in a specific order, allowing them to overlap, using a technique called painter's algorithm. All window managers which allow the overlapping of windows, but are not compositing window managers are considered stacking window managers, although it is possible that not all use exactly the same methodologies. Other window managers that are not considered stacking window managers are those that do not allow the overlapping of windows. These are called tiling window managers.

Stacking window managers allow windows to overlap by drawing them one at a time. Stacking, or repainting (in reference to painter's algorithm) refers to the rendering of each window as an image, painted directly over the desktop, and over any other windows that might already have been drawn, effectively erasing the areas that are covered. The process usually starts with the desktop, and proceeds by drawing each window and any child windows from back to front, until finally the foreground window is drawn.

The order in which windows are to be stacked is called their z-order.

Limitations

Stacking is a very slow process, requiring the redrawing of every window one-by-one, from the rear-most and outer-most to the front most and inner-most. Many stacking window managers don't always redraw background windows. Others can detect when a redraw of all windows is required, as some applications request stacking when their output has changed. Re-stacking is usually done through a function call to the window manager, which selectively redraws windows as needed. For example if a background window is brought to the front, only that window should need to be redrawn.

A well-known disadvantage of stacking is that when windows are painted over each other, they actually end up erasing the previous contents of whatever part of the screen they are covering. Those windows must be redrawn when they are brought to the foreground, or when visible parts of them change. When a window has changed or when its position on the screen has changed, the window manager will detect this and may re-stack all windows, requiring that each window redraw itself, and pass its new appearance along to the window manager before it is drawn. When an application stops responding, it may be unable to redraw itself, which sometimes causes the area within the window frame to retain images of other windows when it is brought to the foreground. This problem is commonly seen on Windows XP and earlier, as well as some X window managers.

Another serious limitation that affects almost all stacking window managers is that they are often severely limited in the degree to which the interface can be accelerated by a graphics processing unit (GPU), and very little can be done about this.

Avoiding limitations

Some technological advances have been able to reduce or remove some of the disadvantages of stacking. One possible solution to the limited availability of hardware acceleration is to treat a single foreground window as a special case, rendering it differently from other windows.

This does not always require a redesign of the window manager because a foreground window is drawn last, in a known locations of the screen, and is not covered by any other windows. Therefore it can be easily isolated on the screen after it has been drawn. For one, since we know where the foreground window is, when the screen raster reaches the graphics hardware, the area occupied by the foreground window can be easily replaced with an accelerated texture.

However if the window manager is also able to supply an application with an updated image of what the screen looked like before the foreground window was drawn but after all other windows were already drawn more possibilities open up. This would allow the one window in the foreground to appear semi-transparent, by using the before image as a texture filter on the final output. This was possible in Windows XP with software included with many NVidia GeForce video cards as well as from third party sources, using a hardware texture overlay.

Another method of lessening the limitations of stacking is through the use of a hardware overlay and chroma keying. Since the video hardware can draw on the outgoing screen, a window is drawn containing a known colour, which allows the video hardware to detect which parts of the window are showing and should be drawn on. 3D and 2D accelerated video and animation may be added to windows using this method.

Full screen video may also be considered a way of avoiding limitations imposed by stacking. Full screen mode temporarily suspends the need for any window management, allowing applications to have full access to the video card. Accelerated 3D games under Windows XP and earlier relied totally on this method, as these games would not have been possible to play in windowed mode. However technically this method has nothing to do with the window manager, and is simply a means of superseding it.

Hybrid window managers

Some window managers may be able to treat the foreground window in an entirely different way, by rendering it indirectly, and sending its output to the video card at to be added to the outgoing raster. While this technique may be possible to accomplish within some stacking window managers, it is technically compositing, with the foreground window and the screen raster being treated the same way two windows would be in a compositing window manager.

As described earlier, we might have access to a slightly earlier stage of stacking where the foreground window has not been drawn yet. Even if it is later drawn and set to the video card, it is still possible to simply overwrite it entirely at the hardware level with the slightly out of date version, and then create the composite without even having to draw in the original location of the window. This allows the foreground window to be transparent, or even three dimensional.

Unfortunately interacting with objects outside the original area of the foreground window might also be impossible, since the window manager would not be able to determine what the user is seeing, and would pass such mouse clicks to whatever programs occupied those areas of the screen during the last stacking event.

AmigaOS

Main article: Workbench (AmigaOS)

Workbench is the stacking windows manager of AmigaOS. In AmigaOS 1.1, 1.2, and 1.3 The windows are all drawn by internal graphic Library called Workbench.Library, which contains all graphical primitives for creating the entire desktop GUI elements and it is powered by another internal library, that works as GUI engine and is called Intuition, that is a powerful intelligent system capable to recognize what windows are foreground, what windows are background and how much of their surface is covered by foreground windows... It performs intelligent redraw of just only those parts of the screen that required to be refreshed by made large use of internal hardware circuits of Amiga called Bit Blitter capable to move entire portions of square graphics, and by Copper circuit, that pilots eltectonic beam of the screen and starts redraws only at desired location. Intuition also pilots the mouse pointer that is a sprite object floating on a 320x256 low res transparent screen superimposed over the main 640x256 desktop screen. Intuition controls collision of the pointer sprite with background elements of the desktop (icons, menus, windows and their titlebars, close gadgets, resize gadgets). The engine also anticipates the chioices of the user by veryifing the position of the mouse over the various screen objects... For example if mouse pointer is floating above a close gadget, then Intuition is capable to predict that the only future action by the user could be the closing of the windows or move away, and starts a parallel procedure containing the preliminary actions to close the window. If the user truly closes the window, Intuition will pass immediately the procedure to Workbench and redraws the screen according to user command. This fact will result in almost zero-wait GUI experience for the user.

X Window System

Main article: X window manager

Stacking window managers under the X window system have the same limitations as any other stacking window manager on any other platform except one: they are fully interchangeable. With the addition of XComposite, this parenting information may be used in different ways, including the implementation of compositing window managers, or ignored as the case may be with tiling window managers, but regardless of its presence or absence full application support is maintained, allowing virtually all programs written for one window manager to work seamlessly with any other.

The following Window Manager packages provide stacking window functionality:

• 9wm
• aewm
• aewm++
• amiwm
• awesome - A dynamic window manager that provides both tiling and stacking capabilities
• blackbox
• enlightenment
• evilwm
• fluxbox
• fvwm
• fvwm95
• icewm
• ion - Provides both tiling and stacking capabilities
• larswm - Provides both tiling and stacking capabilities
• Lightweight window manager
• mwm
• olwm
• openbox
• sithwm
• tritium
• trswm
• twm
• windowlab

Microsoft Windows

A Windows for Workgroups 3.11 desktop, which uses a stacking window manager.

Windows has used stacking ever since Windows 2.0, with the addition of overlapping windows. Prior to that, Windows used a tiling window manager. This window manager has remained virtually unchanged since then.

Windows XP still exclusively uses a stacking window manager, which has presented severe limitations to its ability to display hardware-accelerated content inside normal windows, although it is technically possible to produce some visual effects using third-party software. Windows Vista abandoned this technology in favor of a compositing window manager.

History

Main article: History of the graphical user interface

• (1970s) The Xerox Alto which contained the first working commercial GUI used a stacking window manager.
• (Early 1980s) The Xerox Star, successor to the alto, used tiling for most main application windows, and used overlapping only for dialogue windows removing the need for full stacking.
• Mac OS was one of the earliest commercially successful examples of an GUI which used stacking windows.
• GEM 1.1 predated Microsoft Windows and used stacking, allowing all windows to overlap. As a result of a lawsuit by Apple, GEM was forced to remove the stacking capabilities.
• Amiga OS contains an early example of a highly advanced stacking window manager.

See also

• Window manager

External links

• http://toastytech.com/guis/