This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)
In computing, a windowing system (or window system) is software that manages separately different parts of display screens. It is a type of graphical user interface (GUI) which implements the WIMP (windows, icons, menus, pointer) paradigm for a user interface.
Each currently running application is assigned a usually resizable and usually rectangular surface of the display to present its GUI to the user; these windows may overlap each other, as opposed to a tiling interface where they are not allowed to overlap. Usually a window decoration is drawn around each window. The programming of both the window decoration and of available widgets inside of the window, which are graphical elements for direct user interaction, such as sliders, buttons, etc., is eased and simplified through the use of widget toolkits.
The main component of any windowing system is usually called the display server, although alternative denominations such as window server or compositor are also in use. Any application that runs and presents its GUI in a window, is a client of the display server. The display server and its clients communicate with each other over a communications protocol, which is usually called display server protocol, the display server being the mediator between the clients and the user. It receives all the input from the kernel, that the kernel receives from all attached input devices, such as keyboard, pointing devices, or touchscreen and transmits it to the correct client. The display server is also responsible for the output of the clients to the computer monitor. The output of sound is usually not managed by the display server, but the sound volume is usually handled through GUI applets and it is the display server who decides which applications are on top. A windowing system enables the computer user to work with several programs at the same time. Each program presents its GUI in its own window, which is generally a rectangular area of the screen.
From a programmer's point of view, a windowing system implements graphical primitives. For example: rendering fonts or drawing a line on the screen. It provides an abstraction of the graphics hardware for use by higher-level elements of the graphical interface such as a window manager.
A display server or window server is a program whose primary task is to coordinate the input and output of its clients to and from the rest of the operating system, the hardware, and each other. The display server communicates with its clients over the display server protocol, a communications protocol, which can be network-transparent or simply network-capable.
The display server is a key component in any graphical user interface, specifically the windowing system.
Display server communications protocols
One example of a display server is the X.Org Server, which runs on top of the kernel (usually a Unix-like kernel, such as Linux or BSD). It receives user input data (e.g. from evdev on Linux) and passes it to one of its clients. The display server also receives data from its clients; it processes the data, it does the compositing and on Linux it passes the data to one of three kernel components – DRM, gem or KMS driver. The component writes the data into the framebuffer and content of the framebuffer is transmitted to the connected screen and displayed. X relies on GLX.
One of the implementations of display server concept is X Window System, in particular its actually used version – X.Org Server and Xlib and XCB client libraries. The X.Org Server is a display server, but in its current implementation it relies on a second program, the compositing window manager, to do the compositing. Examples are Mutter or KWin.
Notable examples of display servers implementing the X11 display server protocol are X.Org Server, XFree86, XQuartz and Cygwin/X, while client libraries implementing the X11 display server protocol are Xlib and XCB.
Display servers that implement the Wayland display server protocol, are called Wayland compositors. Like any display server, a Wayland compositor is responsible for handling input and output for its clients and – in contrast to X11 – additionally for the compositing. Examples are Weston, Mutter, KWin or Enlightenment.
Wayland compositors communicate with Wayland clients over the Wayland display server protocol. This protocol defines that clients can directly write data into the framebuffer using the EGL rendering API. The display server still gets to decide which window is on top and thus visible to the user and also still is responsible for passing data regarding to input devices from evdev to its clients.
Wayland is used to a certain degree in some Linux desktop distributions, such as Fedora. It is also well suited for mobile computing and has been adopted, for example, by the smartphone- and tablet-focused projects Tizen, Sailfish OS and AsteroidOS.
The Mir display server comes with its own Mir display server protocol which is different from those used by X11 and Wayland. Mir additionally supports the X11 protocol. It was developed by Canonical and was intended to be the display server of choice for Ubuntu. As of 2017, it has been replaced with the Wayland display server for desktop editions of Ubuntu.
There are implementations of the Mir display server, the libmir-server and the libmir-client libraries available under the GPLv3.
Yet another Android-specific solution is "Gralloc". Gralloc handles device memory i.e. it does allocation, arbitration, it handles synchronization via Android/Linux fence file descriptors. Gralloc competes with other solutions like e.g. Mesa's Generic Buffer Management (GBM) or Nvidia's EGLStreams. The Gralloc hardware abstraction layer (HAL) is used to allocate the buffers that underlie "surfaces".
For compositing in Android, Surfaces are sent to SurfaceFlinger, which uses OpenGL ES to do the compositing.
Hardware Composer HAL (HWC) was introduced in Android 3.0 and has evolved steadily over the years. Its primary purpose is to determine the most efficient way to composite buffers with the available hardware. As a HAL, its implementation is device-specific and usually done by the display hardware OEM.
Desktop Window Manager
For Microsoft Windows, from Windows Vista onward, Desktop Window Manager enables the use of hardware acceleration to render the graphical user interface. It was originally created to enable portions of the new "Windows Aero" user experience, which allowed for effects such as transparency, 3D window switching and more. It is also included with Windows Server 2008, but requires the "Desktop Experience" feature and compatible graphics drivers to be installed. From Windows 8 onwards DWM can't be disabled and is software rendered if no suitable graphics card is installed.
List of windowing systems
- 8½ and rio for Plan 9
- FramebufferUI in-kernel windowing system
- HP Windows/9000 (on early versions of HP-UX)
- Sapphire for the PERQ
- ManaGeR (MGR)
- NeWS / OpenWindows
- NeXT DPS
- Orbital (Redox)
- Qt Extended
- Quartz Compositor (Mac OS X)
- Twin (Text WINdows)
- W Window System
- X Window System
For Windows NT-family operating systems
- Desktop Window Manager (DWM) in Microsoft Windows (Vista and later)
- ReactOS Explorer
- Classic Shell
- Talisman Desktop
Commercial systems such as Microsoft Windows (XP, 9x and earlier), the classic Mac OS (version 9 and earlier), and Palm OS, contain a windowing system which is integrated with the OS.
- Kent, Allen; Williams, James G. (1996-10-11). Encyclopedia of Microcomputers: Volume 19 - Truth Maintenance Systems to Visual Display Quality. CRC Press. p. 227. ISBN 9780824727178. Retrieved 8 June 2017.
- "Ozone Overview". Retrieved 2017-08-20.
- "Android system architecture" (PDF). Archived from the original (PDF) on 2016-04-08.
- "Android Developer: Surface".
- "Android Developer: SurfaceFlinger and Hardware Composer".
- "HP Windows/9000 User's Manual" (PDF). Hewlett Packard. April 1988. Retrieved 2021-10-26.
- Myers, Brad (Dec 1984). "The User Interface for Sapphire" (PDF). IEEE Computer Graphics and Applications. 4 (12): 13–23. doi:10.1109/MCG.1984.6429376.