KDE Commit-Digest
KWin versions in recent KDE 3.x releases included a stand-alone compositing manager called kompmgr, based on the xcompmgr compositing manager. Kompmgr was only loosely tied up with KWin, used only XRender for rendering, and provided only basic features like transparency, shadows, and fade in/out animations. The compositing manager implemented in the version of KWin included with KDE 4.0 is integrated into the rest of KWin, and it can use either OpenGL or XRender for rendering and has a framework for compositing effects, all of which allows KWin to provide a much wider range of features.
Note, however, that compositing support in KWin in KDE 4.0 is still considered experimental, for several reasons. System support for compositing is often problematic (various bugs in the X server, drivers, or other parts of the system), some applications may not be prepared and work well with compositing, the performance may not be adequate, and other problems. Also, while KWin's compositing support is considered usable and reasonably stable, it is relatively new code and has been tested only on a limited range of hardware.
Therefore, compositing support in KWin is disabled by default, and needs to be explicitly enabled. If there are any problems, you can disable it again and report a bug with all relevant information about the problem.
Similar to older KWin versions, it is possible to use KWin with other desktop environments or even as a standalone window manager, as long as the required KDE libraries are installed. Please note that KWin is a pure window manager, and does not provide a panel or handle desktop backgrounds like some window managers do. KWin's compositing features work in the standalone mode, with some functionality missing (because of a missing taskbar, for example), and, while this has not been tested, it is expected that compositing features will work also when running in other desktop environments, possibly with some functionality missing again. Reports on using KWin with other desktop environments are welcome.
Compositing works internally by redirecting window drawing to offscreen memory and composing it on the screen in an additional drawing pass. This means that, in general, a composited desktop (on average) has worse performance than a non-composited desktop (although in some cases it may perform better, be that real improvement (or just perceived) due to animations, better synchronization or similar factors). For example, binding window pixmaps to OpenGL textures (that is, preparing window contents for drawing) can be a relatively costly operation with large windows, making things like animations in a Plasma desktop window or page scrolling in a maximized browser window jerky. Heavy system load can also cause the compositing manager to not repaint often enough, resulting in lagging or jerky screen redrawing.
KWin in KDE 4.0 is also relatively new code, and has not been extensively optimized yet, therefore its performance may not be in some areas comparable with performance of other compositing managers. In such cases performance should be improved with newer versions.
Note that current XRender implementations (in X/drivers) often perform rather poorly and therefore the OpenGL mode should usually have much better performance.
As already said, compositing support in KWin is considered usable and reasonably stable, but due to several reasons it may not work properly for you.
KWin provides support for writing compositing effects that may be loaded into KWin as plugins. These effects communicate with the KWin core using C++ API specially designed for this purpose, making effects not directly dependent on the KWin core or changes in it.
At the time of the KDE 4.0 release, since compositing support is still under heavy development, this API is considered unstable and subject to change. If you write your own effect plugin, you may need to recompile it after a KWin update. KWin will however detect incompatible versions and will not load such plugins (automatic, you do not need to provide any code for it). As the compositing support becomes more stable, this API will be kept backwards and binary compatible just like with other KDE libraries.
At the moment, the API for compositing effects is unfortunately only sparsely documented. Developers interested in writing compositing effects for KWin are suggested to use source code of effects shipped with KWin (the Howto effect in test/ directory as the starting point) and/or ask on the KWin mailing list.
Links to various KWin-related documents are available at Techbase.
Why Not Compiz?
It is possible to use Compiz instead of KWin with KDE, however KWin remains the default window manager. The option of replacing KWin with Compiz had been evaluated before work on compositing features of KWin started and the conclusion was, in short, that it would lead to a lot of work and duplicated effort.
To answer in more detail, several technical things need to be explained. Both KWin and Compiz are a combined window manager and compositing manager. Window manager functionality takes care of all aspects of handling windows, such as their placement, selecting the active one and so on. This functionality is crucial for a desktop - without a window manager it would be very difficult to perform most operations with windows. Compositing manager functionality, on the other hand, can be considered optional - while it brings many new features, it is still very possible to use a desktop (such as with KWin in KDE3).
The reasons to add compositing support to KWin instead of using Compiz include:
- Compiz at the present time is very likely the most advanced compositing manager with many features, with a headstart when compared with KWin, however, this cannot be said about Compiz as the window manager, where KWin has the advantage of being a much more tested codebase, providing a more stable, well-tested and robust window manager with many features. Given that, as stated above, window manager functionality is considered to be more important, it would be unwise to force all KDE users to a change that would likely mean regressions in many aspects.
These regressions would include lesser integration with KDE, visual and behavioral changes (the 'KDE window decorator' shipped with Compiz only mimics the look of KWin's decorations, but does not provide the same functionality, even the Alt+F3 popup menu visibly differs), possible introduction of problems that have already been fixed in KWin, missing features that have already been implemented in KWin, and so on. Developing, testing and bugfixing a window manager can be very demanding work and repeating all the work done on KWin again for Compiz would presumably require a lot of effort. As such, claims that KWin is 'reinventing the wheel' are missing the point, since Compiz, being a relatively new window manager, is re-inventing at least as much, if not more, from other window managers including KWin,
Also, given that there can be only one window manager and one compositing manager at a time, there would be no possible way to remedy these problems by somehow running Compiz and KWin together. - Compiz currently does not work at all when compositing is not possible, thus requiring a fallback window manager for such case. This in practice would mean that KDE developers would be required to work on improving Compiz and would have to keep KWin at least for maintenance as the fallback for Compiz, thus having two window managers for KDE. Besides the developer work of taking care of two window managers this would also bring many user problems resulting from two different window managers, with differences in the look and feel, feature sets, and bugs.
It should be also noted that Metacity, GNOME's window manager, has not been dropped in favour of Compiz either, but is still, to our knowledge, under development and adding compositing features to it is a work in progress.
Why not use plugins from Compiz?
This option was considered in the past as well. After examination of Compiz code the conclusion was that this is technically almost impossible. Compiz plugins appear to be merely parts of Compiz that are separated from its core, but which still heavily depend on it - there are even plugins that appear to copy and paste parts of the Compiz core and modify it. Making it possible to use such plugins from KWin would essentially require KWin to become Compiz.
Why add compositing support to KWin when Compiz is better?
There can be different ideas about what better means, but regardless of that, the main aim of KWin is not to replace Compiz. Many users have asked for compositing support in KDE, and, as explained in "Why not Compiz?", the best way to achieve that is considered to be adding compositing support to KWin. KWin aims to provide compositing support, focusing on providing useful compositing features and basic visual effects, while keeping its other strengths.
Here is a video, shown in Aaron Seigo's keynote at the KDE 4.0 Release Event (recorded by Korneliusz of jarzebski.pl), showing the new functionality of the KDE 4.0 KWin:
