|
|
|
|
Desktop Window Manager
|
| |
|
| |
Desktop Window Manager (DWM, previously Desktop Compositing Engine or DCE) is a compositing window manager, introduced with Windows Vista, that enables the Windows Aero graphical user interface and visual theme. The Desktop Window Manager requires video cards supporting DirectX 9.0 and Shader Model 2.0. DWM is not included with Windows Vista Starter edition. It is included with Windows Vista Home Basic edition, but with some aspects of the Windows Aero interface (such as transparent Glass and Flip 3D) disabled.
Discussion
Ask a question about 'Desktop Window Manager' Start a new discussion about 'Desktop Window Manager' Answer questions from other users |
Encyclopedia
Desktop Window Manager (DWM, previously Desktop Compositing Engine or DCE) is a compositing window manager, introduced with Windows Vista, that enables the Windows Aero graphical user interface and visual theme. The Desktop Window Manager requires video cards supporting DirectX 9.0 and Shader Model 2.0. DWM is not included with Windows Vista Starter edition. It is included with Windows Vista Home Basic edition, but with some aspects of the Windows Aero interface (such as transparent Glass and Flip 3D) disabled. It is also included with Windows Server 2008, but requires the "Desktop Experience" feature and compatible graphics drivers to be installed.
Architecture
With the Desktop Window Manager, applications do not draw directly to the video memory; instead, they draw their contents to off-screen buffers in system memory that are then composited together by DWM to render the final screen, a number of times per second. In that sense, it is similar to the Quartz Compositor in Mac OS X. Because the compositor has access to the graphics of all applications, it easily allows visual effects that string together visuals from multiple applications, such as transparency. The DWM uses DirectX 9 to perform the function of compositing and rendering in the GPU, freeing the CPU of the task of managing the rendering from the off-screen buffers to the display. However, it does not affect applications painting to the off-screen buffers; depending on the technologies used for that, it might still be CPU-bound. DWM-agnostic rendering techniques like GDI are redirected to the buffers by rendering the UI as bitmaps. DWM-aware rendering technologies like WPF directly make the internal data structures available in a DWM-compatible format. The window contents in the buffers are then converted to DirectX textures.
The desktop itself is a full-screen Direct3D surface, with windows being represented as a mesh consisting of two adjacent (and mutually-inverted) triangles, which are transformed to represent a 2D rectangle. The texture, representing the UI chrome, is then mapped onto these rectangles. Window transitions are implemented as transformations of the meshes, using shader programs. With Windows Vista, the transitions are limited to the set of built-in shaders that implement the transformations. Greg Schechter, a developer at Microsoft has suggested that it might be opened up for developers and users to plug in their own effects in a future release. The DWM only maps the primary desktop object as a 3D surface; other desktop objects, including virtual desktops as well as the secure desktop used by User Account Control are not.
Since all applications render to an off-screen buffer, they can be read off the buffer embedded in other applications as well. Since the off-screen buffer is constantly updated by the application, the embedded rendering will be a dynamic representation of the application window and not a static rendering. This is how the live thumbnail previews, Windows Flip and Windows Flip 3D work in Windows Vista. The DWM exposes a public API that allows applications to access these thumbnail representations. The size of the thumbnail is not fixed; applications can request the thumbnails at any size - smaller than the original window, at the same size or even larger - and DWM will scale them properly before returning. Windows Flip 3D uses the thumbnail APIs to get the window representations as bitmaps, and then uses that as texture for 2D rectangles, which are further processed by custom shaders to transform them to 3D meshes and rotate them in a 3D plane.
The Desktop Window Manager uses Media Integration Layer (MIL), the unmanaged compositor which it shares with Windows Presentation Foundation, to represent the windows as composition nodes in a composition tree, representing the desktop and all the windows hosted in it, which are then rendered by MIL from back of the scene to the front. Since all the windows contribute to the final image, the color of a resultant pixel can be decided by more than one window. This is used to implement effects such as per-pixel transparency. DWM allows custom shaders to be invoked to control how pixels from multiple applications are used to create the resultant pixel. The DWM includes built-in Pixel shader 2.0 programs that computes the color of a pixel in a window by averaging the color of the pixel as determined by the window behind it and its neighboring pixels. These shaders are used by DWM to achieve the blur effect in the window borders of windows managed by DWM, and optionally for the areas where it is requested by the application.
Since MIL provides a retained mode graphics system by caching the composition trees, the job of repainting and refreshing the screen when windows are moved is handled by DWM and MIL, freeing the application of the responsibility. The background data is already in the composition tree and the off-screen buffers, that is directly used to render the background, without having the background applications to re-render themselves by sending them the WM_PAINT message, as was the case with pre-Vista Windows OSs. DWM uses double-buffered graphics to prevent flickering and tearing during window moves. The compositing engine uses optimizations such as culling to improve performance, as well as not redrawing areas that haven't changed. Because the compositor is multi-monitor aware, the DWM natively supports that too.
During full-screen applications, such as games, the DWM does not perform window compositing and therefore performance will not appreciably decrease.
Redirection
For rendering techniques that are not DWM-aware, output must be redirected to the DWM buffers. With Windows, either GDI or DirectX can be used for rendering. To make these two work with DWM, redirection techniques for both are provided with DWM.
With GDI, which is the most used UI rendering technique in Microsoft Windows, each application window is notified when it or a part of it comes in view and it is the job of the application to render itself. Without DWM, the rendering rasterizes the UI in a buffer in video memory, from where it is rendered to the screen. Under DWM, a buffer equal to the size of the window is allocated in system memory. GDI calls are redirected to write their outputs to this buffer, rather than the video memory. Another buffer is allocated in the video memory to represent the DirectX surface, which is used as the texture for the Window meshes. The system memory buffer is converted to the DirectX surface separately, and kept in sync. This round-about route is required as GDI cannot output directly in DirectX pixel format. The surface is read by the compositor and is composited to the desktop in video memory. Writing the output of GDI to system memory is not hardware accelerated, nor is conversion to DirectX surface. When a GDI window is minimized, by the limitations of GDI, the buffer is no longer updated. So, DWM uses the last bitmap rendered to the buffer before the application was minimized.
For applications using DirectX to write to a 3D surface, the DirectX implementation in Windows Vista uses WDDM to share the surface with DWM. DWM then uses the surface directly and maps it on to the window meshes. For WPF applications, which are DirectX applications, the compositor renders to such shared surfaces, which are then composited into the final desktop. Applications can mix either rendering technique across multiple child windows, as long as both GDI and DirectX are not used to render the same window. In that case, the ordering between DirectX and GDI rendering cannot be guaranteed, and as such it cannot be guaranteed whether the GDI bitmap from the system memory has been translated to the video memory surface. So, the final composition may not contain the GDI-rendered elements. To prevent this, DWM is temporarily turned off, as long as an application which mixes GDI and DirectX in the same window is running.
Hardware requirements
DWM requires compatible phyical or virtual hardware:
- A GPU that supports the Windows Driver Display Model (WDDM)
- DirectX 9 support
- Pixel Shader 2.0 support,
- Support for 32 bits per pixel
- Passes the Windows Aero acceptance test in the Windows Driver Kit (WDK)
As of February 2009, neither Hyper-V nor VMware virtual machines meet the hardware requirements.
External links
|
| |
|
|
