You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
248 lines
15 KiB
248 lines
15 KiB
KWin release notes for KDE4.0 |
|
============================= |
|
|
|
= Introduction = |
|
|
|
KWin, the standard KDE window manager, in KDE4.0 ships with the first version |
|
of built-in support for compositing, making it also a compositing manager. |
|
This allows KWin to provide advanced graphical effects, like for example with Compiz, |
|
while also providing all the features from previous KDE releases (such as very good |
|
intergration with the rest of KDE, advanced configurability, focus stealing prevention, |
|
well-tested window manager, robust handling of misbehaving applications/toolkits, etc.). |
|
Unlike Compiz, KWin still functions even when no system support for compositing is |
|
available, with only compositing features not being available in such case. |
|
|
|
Previous KWin versions in later KDE3.x releases included a standalone compositing |
|
manager called kompmgr, based on the xcompmgr compositing manager. Kompmgr was only |
|
loosely tied with KWin, used only XRender for rendering and provided only basic |
|
features like transparency, shadows and fade in/out animations. Compositing manager |
|
in KWin in KDE4.0 is integrated with the rest of KWin, can use either OpenGL or XRender |
|
for rendering and has a framework for compositing effects, all these allowing KWin |
|
to provide a much wider range of features. |
|
|
|
Note, however, that compositing support in KWin in KDE4.0 is still considered experimental, |
|
for several reasons. System support for compositing is often being problematic (various bugs |
|
in X, drivers or other parts of the system), manual configuration of X may be required |
|
for proper results (see below), 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 will be any problems, you can disable it again (see below for troubleshooting) |
|
and report a bug with all relevant information about the problem. |
|
|
|
|
|
= Setting up = |
|
|
|
Compositing support is enabled in KWin's configuration. Press Alt+F3 and select 'Configure Window |
|
Behavior'. In the configuration module, select page 'Desktop Effects' and enable checkbox |
|
'Enable desktop effects'. After accepting the changes, a dialog with a timeout will appear, |
|
asking to confirm enabling of compositing support. If you do not confirm within the timeout, |
|
compositing support will be disabled again, therefore, if enabling compositing triggers |
|
any problems, it should be sufficient to wait several seconds before the changes are reverted. |
|
Note that after enabling or disabling compositing it is recommended to restart your KDE |
|
session in order to ensure that all applications detect the change. |
|
|
|
If you cannot enable desktop effects, it may be because either your KDE is not built |
|
with necessary support, or more probably because your system is not capable of providing |
|
compositing support. See file |
|
http://websvn.kde.org/*checkout*/trunk/KDE/kdebase/workspace/kwin/COMPOSITE_HOWTO |
|
for some instructions on setting up your system. Note that there may be other factors |
|
affecting whether you do or do not have compositing support. |
|
|
|
|
|
= Usage = |
|
|
|
A quick overview of features provided by compositing manager in KWin: |
|
|
|
- Ctrl+F9 (and Ctrl+F10 for windows from all desktops) shows an overview of all windows |
|
and allows activating one of them. The feature can be also activated by moving the mouse |
|
into the top-left screen corner. A window can be activated by clicking it or by using arrows |
|
and Enter key. You can also type text to filter the list of windows. |
|
- Ctrl+F8 shotcut activates a desktop grid - all your virtual desktops will be arranged |
|
on the screen (as an enlarged pager) - you can select and activate desktops using |
|
a number, a function key, by clicking on it or by using arrows and Enter key, |
|
you can move windows by dragging them or by right-clicking on them. |
|
- The DesktopGrid effect also provides animations when switching between virtual desktops (can |
|
be turned off). |
|
- The window switcher (Alt+Tab by default) provides live thumbnails of windows. |
|
- Windows blocked by modal dialogs are dimmed. |
|
- Screen can be zoomed in and out using Win+<equals>, Win+<minus> and reset using Win+0 ( |
|
it is currently not possible to use mouse wheel, but this feature is planned). Note that |
|
because of input transformation not being yet available in X the zoomed screen has to move |
|
around to keep the mouse pointer at the same place like it would be when not zoomed. |
|
- Screen can be shown with inverted colors by pressing Ctrl+Win+I (accessibility feature, |
|
Invert effect is not enabled by default). |
|
- There are fade animations during login and logout. |
|
- Windows fade in and out. |
|
- Minimize animation to/from taskbar. |
|
- Windows have shadows. |
|
|
|
There are more features that are not enabled by default and need to be explicitly enabled |
|
in the configuration. |
|
|
|
There are various videos showing various compositing features of KWin. For example, |
|
search for 'kwin_composite' at youtube.com (please keep in mind that many of those windows |
|
are old and show testing or demo effects). |
|
|
|
|
|
= Using KWin without KDE desktop = |
|
|
|
Just like with older KWin versions it is possible to use KWin also with other desktop |
|
environments or even as a standalone window manager, as long as required KDE libraries |
|
are installed. Please note that KWin is a pure window manager and does not provide a panel |
|
or handle desktop background like some window managers do. KWin's compositing features |
|
work in the standalone mode, with some functionality missing (because of 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. |
|
|
|
|
|
= Performance = |
|
|
|
Compositing internally works by redirecting window drawing to offscreen memory and composing |
|
it on the screen in an additional drawing pass. This means that in general composited desktop |
|
on average has worse performance that non-composited desktop (although in some cases it |
|
may perform better, be that real improvement or just perceived one 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 Plasma desktop window or page scrolling |
|
in a maximized browser window jerky. Heavy system load can also cause the compositing manager |
|
not repaint often enough, resulting in lagging or jerky screen redrawing. |
|
|
|
KWin in KDE4.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 usually should have much better performance. See below for notes |
|
on XRender mode. |
|
|
|
Tip: Performance/smoothness with nVidia cards: Smoothness of KWin rendering |
|
can be improved by setting env.variable KWIN_NVIDIA_HACK to 1 (e.g. append |
|
"export KWIN_NVIDIA_HACK=1" to your ~/.profile file). This sets __GL_YIELD=NOTHING |
|
for KWin, letting KWin use more CPU time for OpenGL operations, however |
|
at the expense of affecting performance of other applications. This is |
|
therefore disabled by default. This setting may be removed in the future |
|
if the negative impact becomes insignificant. See section "OPENGL YIELD BEHAVIOR" |
|
in README.txt for nVidia cards. |
|
|
|
|
|
= Troubleshooting = |
|
|
|
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. |
|
|
|
If there are any problems with compositing support, the simplest option is to disable |
|
it again. KWin will normally continue functioning, only not providing compositing features. |
|
If you cannot normally turn off compositing support (for example because the screen |
|
is corrupted), you can turn it off using one of these ways: |
|
- run command 'kwriteconfig --file kwinrc --group Compositing --key Enabled false' from |
|
the command line |
|
- set environment variable 'KWIN_COMPOSE' to 'N' (append 'export KWIN_COMPOSE=N' at the end |
|
of your ~/.profile), this affects compositing only temporarily |
|
You will probably need to switch to text mode or start failsafe session from KDM to be |
|
able to perform this. |
|
|
|
See file http://websvn.kde.org/*checkout*/trunk/KDE/kdebase/workspace/kwin/COMPOSITE_HOWTO |
|
for some issues with various graphics cards. |
|
|
|
|
|
= XRender mode = |
|
|
|
It is possible to use XRender for compositing instead of the default OpenGL. |
|
XRender mode in general has less features, however at the moment it is also considered |
|
unstable - it has not received as much testing as OpenGL mode, some features may be incomplete |
|
and it is recommended to use the OpenGL mode if possible. Also note that current XRender |
|
implementations (in X/drivers) often perform rather poorly. |
|
|
|
|
|
= Developers = |
|
|
|
KWin provides support for writing compositing effects that may be loaded into KWin as |
|
plugins. These effects communicate with KWin core using C++ API specially designed for this |
|
purpose, making effects not directly dependent on KWin core and changes in it. |
|
|
|
At the time of the KDE4.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 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 will become more stabilized, this API will be kept backwards and |
|
binary compatible, just like with other KDE libraries. |
|
|
|
At the time of the KDE4.0 release, 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 as the starting point) |
|
and/or ask on the KWin mailing list. |
|
|
|
Links to various KWin-related documents are available at http://techbase.kde.org/Projects/KWin . |
|
|
|
= FAQ = |
|
|
|
== 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 as 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 possible very well |
|
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 more stable, well-tested |
|
and robust window manager, with many features. Given that, as said 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 a 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 reinventing 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 not be possibly a 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 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.
|
|
|