The extension handling is removed from kwinglobals and moved into the
xcbutils in KWin core in namespace KWin::Xcb. The motivation for this
change is that the Extensions are only used in KWin core and are marked
as internal. So there is no need to have them in the library.
What remains in Extensions are the non-native pixmaps. This will be
removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap.
The remaining code in kwinglobals also still initialize the XLib versions
of extensions emitting events. It seems like there are no XEvents emitted
if not done so even if the extension is correctly initialized with xcb.
This needs to be removed once the event handling is ported over to xcb.
REVIEW: 107832
Most windows use the hostname in WM_CLIENT_MACHINE, but there are windows
using the FQDN (for example libreoffice). So instead of "foo" it is
"foo.local.net" or similar. The logic so far has been unable to properly
determine whether windows with FQDN are on the local system.
In order to solve this problem the handling is split out into an own
class which stores the information of hostname and whether it is a local
machine. This is to not query multiple times. To determine whether the
Client is on the local system getaddrinfo is used for the own hostname
and the FQDN provided in WM_CLIENT_MACHINE. If one of the queried
names matches, we know that it is on the local machine. The old logic to
compare the hostname is still used and getaddrinfo is only a fallback in
case hostname does not match.
The problem with getaddrinfo is, that it accesses the network and by that
could block. To circumvent this problem the calls are moved into threads
by using QtConcurrent::run.
Obviously this brings disadvantages. When trying to resolve whether a
Client is on the local machine and a FQDN is used, the information is
initially wrong. The new ClientMachine class emits a signal when the
information that the system is local becomes available, but for some
things this is just too late:
* window rules are already gathered
* Session Management has already taken place
In both cases this is an acceptable loss. For window rules it just needs
a proper matching of the machine in case of localhost (remote hosts are
not affected). And the case of session management is very academic as it
is unlikely that a restoring session contains remote windows.
BUG: 308391
FIXED-IN: 4.11
REVIEW: 108235
Use XDamageReportNonEmpty instead of XDamageReportRawRectangles.
In XDamageReportNonEmpty mode the server generates a single damage
event when the damage state transitions from not-damaged to damaged.
When the compositor is ready to paint the screen, it requests the
damage region for each window and resets the state to not-damaged.
With XCB we can request the damage regions for all windows in a
single roundtrip, making this the preferred mode.
This should reduce the number of wakeups and the time spent
processing damage events between repaints.
The method windowType needs actually two implementations:
* one for Clients
* one for Unmanaged
as for Clients also the window rules are checked and hacks are applied
which is both not needed for Unmanaged windows.
To have the Client specific behavior in windowType the function used to
perform two dynamic_casts which made this method one of the most
expensive during compositing, e.g. for ~1000 frames
* called ~43000 times
* ~85000 dynamic casts
* incl. cost of method: 0.24
* self cost of method: 0.05
* incl. cost of the casts: 0.12
After the change to remove the dynamic casts we have for ~1500 frames
in Client::windowType:
* called ~31000 times
* incl. cost of 0.06
* self cost of 0.02
Calls on Unmanaged and Deleted are so low that we do not need to consider
them.
BUG: 306384
FIXED-IN: 4.10
REVIEW: 106349
The oo.o related hack can be removed for several reasons:
1. The dialog in question from bug 66065 is nowadays a utility
2. The window class name changed to libreoffice
3. It's not the task of the window manager to workaround bugs in Clients
CCBUG: 66065
BUG: 306383
FIXED-IN: 4.9.2
KDE has not supported the TopMenu in any 4.x release and most of the
TopMenu related code has already been dropped from KWin. It is extremely
unlikely that there is still a window around which would need this
specific check. And even if there were such a check it would be broken.
So let's just remove this hack which means less checks in one of the
hottest code pathes of KWin.
CCBUG: 306383
For most actions where the compositor needs to perform an action
(e.g. scheduling another repaint) signals were already emitted.
So it's easier to just connect the signals to the Compositor
which in turn makes the code much more readable.
All signals are connected from the Workspace when either the
Compositor gets constructed or a Toplevel gets created.
resetting is no longer needed with philip layer changes and actually
breaks damages on simultaneous resizes
also use addLayerRepaint for the shadow update
REVIEW: 104306
Behavior is now like all xinerama related options are enabled.
There seems to be no valid reasons to run multi screen without
xinerama support and even if a user would wish to do so she can
just disable xinerama in xorg.conf.
Furhtermore thanks to KWin scripting it is possible to achieve the
behavior as it used to be with the options disabled. E.g. it is
possible to span a window in fullscreen mode over all screens.
This change is in accordance to the discussion on kwin and plasma
mailinglists:
http://mail.kde.org/pipermail/plasma-devel/2012-January/018542.html
Property invokes virtual methods returning false by default. Deleted
reimplements the isDeleted and returns true. Client returns true for
isClient. Method is not called isManaged as this is already used
inside Client.
This patch implements an XProperty named _KDE_NET_WM_OPAQUE_REGION
which gives the compositor the information which part of a window
is opaque although it is an ARGB visual. The basic ideas are from
http://www.mail-archive.com/wm-spec-list@gnome.org/msg00715.html
Additionally the patch makes kwin use this information to do a better
clipping in Scene::paintSimpleScreen which should result in a higher
performance.
REVIEW: 102933
The method windowOpacityChanged is now a protected slot in class Scene. The implementations in the subclasses SceneOpenGL and SceneXRender are the same. The slots are connected to the singal opacityChanged() from Toplevel. The connection is done in the method windowAdded() in both SceneOpenGL and SceneXRender.
The Shadow is clearly an aspect of the compositor. Therefore the
Shadow has to be owned and controlled by the Scene::Window.
Nevertheless Toplevel needs to know about the Shadow cause of reading
the property.
Unmanaged needs to repaint the complete geometry including shadow
when it ends compositing. Therefore we need to track the shadow
passing to deleted correctly. Disadvantage: when turning off
compositing the shadow is kept. Need to solve in a better way!
For a complete documentation of new functionality refer to:
http://community.kde.org/KWin/Shadow
The current implementation includes a new Shadow class and Toplevel
holds a pointer to an instance of this class. The Shadow class reads
the data from the X11 Property. There is one extended class located
in SceneOpenGL to render the shadow.
Compositor is adjusted to include the shadow region into the painting
passes.
Implementation for XRender still missing and Shadow needs to respond
to size changes of the Toplevel to update cached shadow region and
WindowQuads.
Workspace::activeScreen() when the center of the active client is
offscreen and was not previously on the active screen.
svn path=/trunk/KDE/kdebase/workspace/; revision=925362
and not be slowed down by going through compositing. Turned on and no UI option
in the naive hope that it won't cause any real problems. Maybe effects doing
window previews should get API to suspend unredirect though.
svn path=/trunk/KDE/kdebase/workspace/; revision=851742
