According to Pierre-Loup Griffais (Plagman on IRC) this is causing
choppy VDPAU video playback when compositing is enabled.
Removing these calls doesn't seem to cause any regressions, and the
commit that added them doesn't give a reason. So let's just get rid
of them for now.
This commit should be cherry-picked to the stable branch if no one
else notices any regressions.
CCMAIL: kwin@kde.org
Left over from the cleanup which basically resulted in the active window
being put to the inactive's window opacity.
Thanks for the early notification of that issue.
BUG: 306449
FIXED-IN: 4.9.2
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
The effect should have had two animations:
* on move resize
* on active/inactive change
But the timeline was adjusted in the prePaintWindow call and the timeline
is effect global and not per window. Which means that for each window the
same time is added. So instead of adding time t each frame t*n with n
being the number of windows got added. So in most cases the animation
ended in the first or second frame which means its not visible.
Through git blame I was able to track down that this incorrect behavior
was introduced in 2008. An animation broken for more than four years
without anybody noticing is probably not required. Because of that it's
dropped from the effect. As this includes quite some code and performance
improvements it goes into the release branch.
A better solution could be implemented, but that should be for 4.10.
BUG: 306263
FIXED-IN: 4.9.2
REVIEW: 106335
There were quite some useless checks like e.g. first checking whether
a window is the desktop and taking a different code path for that case
and in the other code path checking again.
Also using the new introduced boolean values for the checks instead of
comparing floating point numbers all the time.
The effect gets a set of boolean values to check whether it is active for
one of the categories (e.g. move resize, decorations).
This allows to easily check whether the effect is active at all, that is
if all values are at 1.0 the effect will never affect a window.
In all other cases it can be combined with looking at the available
windows to e.g. enable the effect for move resize only when there is a
window which is either moved or resized. This check is performed whenever
an action happens which could cause a window to become inactive.
BUG: 306262
FIXED-IN: 4.9.2
Nobody is interested in whether the Abilities are supported.
There is one method in KWin core checking for the colors
supported by the currently loaded decoration:
Workspace::decorationSupportedColors
This method is not called from anywhere inside KWin, but is
part of the D-Bus interface, though nobody in KDE's repository
is calling it [1].
As it is part of public API the Abilities are only deprecated
and scheduled for removal with the next big break.
[1] http://lxr.kde.org/search?filestring=&string=decorationSupportedColors
REVIEW: 105785
A script can register a callback through registerUserActionsMenu to be
informed when the UserActionsMenu is about to be shown. This menu calls
the Scripting component to gather actions to add to a Scripts submenu.
The Scripting component now asks all scripts for the actions, which will
invoke the registered callbacks with the Client for which the menu is to
be shown as argument.
The callback is supposed to return a JSON structure describing how the
menu should look like. The returned object can either be a menu item or
a complete menu. If multiple menu items or menus are supposed to be added
by the script it should just register multiple callbacks.
The structure for an item looks like the following:
{
text: "My caption",
checkable: true,
checked: false,
triggered: function (action) {
print("The triggered action as parameter");
}
}
The structure for a complete menu looks quite similar:
{
text: "My menu caption",
items: [
{...}, {...} // items as described above
]
}
The C++ part of the script parses the returned object and generates
either QAction or QMenu from it. All objects become children of the
scripts QMenu provided by the UserActionsMenu.
Before the menu is shown again the existing menu is deleted to ensure
that no outdated values from no longer existing scripts are around. This
means the scripts are queried each time the menu is shown.
FEATURE: 303756
FIXED-IN: 4.10
REVIEW: 106285
The new methods suspend and resume are meant to provide a better way to
influence the current compositing state than toggleCompositing. In
addition an overload setCompositing(bool) is added. The resume method is
implemented in a way that it can be used to try to start the compositor
again in case it failed.
Internally the method suspendResume is dropped as it does the same as
setCompositing just with inverted binary logic and worse name. The
compositingToggled signal is now emitted from within setup and finish to
ensure that especially the compositingToggled(true) signal is only
emitted if the Compositor could start.
Also the updateCompositingBlocking is adjusted to use the new dedicated
suspend and resume methods instead of the toggle method.
REVIEW: 106273
Two new interfaces are introduced:
* org.kde.kwin.Compositing
* org.kde.kwin.Effects
The Compositing interface is generated from scriptable elements on the
KWin::Compositor class and the Compositor is exported as /Compositor.
It provides the general Compositing related D-Bus methods like whether
the compositor is active and toggling and so on.
The Effects interface is generated from scriptable elements on the
KWin::EffectsHandlerImpl class and the instance is exported as /Effects.
It provides all the effects related D-Bus methods like loading an effect
or the list of all effects.
This removes the need to have all these methods provided on the global
org.kde.KWin interface. For backwards compatibility they are kept, but
no longer provided by the Workspace class. Instead a new DBusInterface
is generated which wrapps the calls and delegates it to one of our three
related Singleton objects:
* Workspace
* Compositor
* EffectsHandlerImpl
The Compositor class actually behaves like a Singleton so it should be
one. Therefore four static methods are added:
* self() to access the Singleton
* createCompositor() to be used by Workspace to create the instance
* isCreated() to have a simple check whether the Singleton is already
created
* compositing() as a shortcut to test whether the compositor has been
created and is active
The isCreated() check is actually required as especially Clients might
be created and trying to access the Compositor before it is setup.
If the start Client is not part of the focus chain the call to
nextClientFocusChain() cannot return the Client again. So the loop break
condition is never reached and as the focus chain is not empty the call
always returns a not null Client which means KWin is caught in an endless
loop.
This change checks that the starting Client is in the focus chain and if
not the first Client of the focus chain is used.
BUG: 306260
BUG: 306275
FIXED-IN: 4.9.2
It seems not all Qt installs will automatically #include QElapsedTimer
from QtCore/QTimer, this caused a build failure on my system and on a
RHEL 6.2 VM I've been testing on.
Checking the Qt docs, QBasicTimer also has a separate include so
although this didn't cause a build failure, I've thrown in its
separate #include as well. I have not checked for other #include errors,
and a very quick search on b.k.o for bugs mentioning "build" did not
return any bugs to close.
I'm pretty sure this build failure applies only to master but I haven't
checked thoroughly.
using color.rgba() for an invalid color corresponds to solid black, which in turns conflicts with the cache
value for such color. We use "transparent black" instead.
CCBUG: 304868
using color.rgba() for an invalid color corresponds to solid black, which in turns conflicts with the cache
value for such color. We use "transparent black" instead.
CCBUG: 304868
if one clicks very fast, the timeout will coincident with the
second downtime (between press and release) what was used to be
interpreted as "still down"
BUG: 305738
REVIEW: 106227
FIXED-IN: 4.9.1
the geometry setting needs to happen out of recursion,
has to be smarter for unmaximizing and also no real
place in TabGroup - the client is no longer tabbed thus
it's not the groups task to manage it's geometry.
BUG: 226881
REVIEW: 106182
FIXED-IN: 4.9.1
