We have lots of inconsistency at the moment in CMakeLists.txt files. Most
of it is due to kwin being a very old project. This change hopefully fixes
all of it.
Summary:
For some historical reasons, the sheet effect uses animation duration of
500ms. In comparison to other effects that animate the appearing and the
disappearing of windows, 500ms is too high value for the duration.
As the title says, this change decreases the default animation duration
to 300ms. The new duration is more saner.
The opacity is animated to make the effect look smoother with the
shorter animation duration.
BUG: 400021
FIXED-IN: 5.15.0
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16359
Summary:
* Use new connect syntax
* Fix coding style
* Port to TimeLine
* Delete unused includes
* Use interpolate helper
* Drop WindowInfo class
Behavior of this effect hasn't been changed.
Test Plan: Opened/closed an "Open File" dialog, it still flies in/out.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, anthonyfieroni, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14685
Summary:
If a modal window is near some of screen edges, it will be distorted
in undesired way when it's being animated.
In order to keep perspective distortions invariant, no matter where
the modal window is on the screen, we have to move that modal window
to the origin, scale it, rotate it, translate it, apply perspective projection,
and then move it back.
Test Plan:
* Opened Kate
* Opened "Open File" dialog (during the in animation, it was distorted as expected)
* Closed that dialog (during the out animation, it was distorted as expected)
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14687
Summary:
If both the Glide effect and the Sheet effect are enabled,
they will conflict. Expected behavior would be:
* the Sheet effect animates only modal windows;
* the Glide effect animates the rest of normal windows.
In order to resolve the conflict, the Sheet effect has to grab
modal windows. Because it's quite specialized effect, we have
to ignore whether modal windows have been grabbed by the
Glide effect.
Test Plan:
* Enabled both the Glide effect and the Sheet effect;
* Opened Kate;
* Opened "Open file" dialog;
* Closed the dialog.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: abetts, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14560
Summary:
When the Sheet effect was written, isModal worked only for Client
windows, not Deleted windows:
bool EffectWindowImpl::isModal() const
{
if( Client* c = dynamic_cast< Client* >( toplevel ))
return c->isModal();
return false;
}
so the Sheet effect had to track windows by using WindowInfo class, e.g.
class WindowInfo
{
public:
bool deleted;
bool added;
bool closed;
};
the biggest drawback of that method is that WindowInfo for each modal kept around
as long as those modals existed. It also was adding little overhead, e.g.
void SheetEffect::paintWindow( EffectWindow* w, int mask, QRegion region, WindowPaintData& data )
{
if( windows.contains( w ) && ( windows[ w ].added || windows[ w ].closed ) )
Things changed with a8160b3c31afa1db24084147ad4ce50cf3c0314a. With that
commit, WindowInfo kept only for modals that are currently being
animated, but isModal still worked only with Client windows, so
IsSheetWindow hack had been introduced.
Long story short: we don't need IsSheetWindow hack anymore because
isModal now works with Deleted windows.
Test Plan: Pressed Ctrl+O in Kate.
Reviewers: #kwin, graesslin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14246
Summary:
By changing all kcfg to have arg="true" we can pass in the same
KSharedConfigPtr into all effects. This allows to have fake config in
the tests and in the planned effect demo mode.
Also it means that we don't have to hardcode the name kwinrc into the
files. In the configs - where we cannot access the effectshandler - we
use the define KWIN_CONFIG which gets generated based on the compile
time arguments.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3571
Summary:
A new method to tell the effects system whether the compositor scene
is able to drive animations. E.g. on software emulation (llvmpipe) it's
better to not do any animations at all.
This information can be used by effects to adjust their behavior, e.g.
PresentWindows could skip transitions or effects can use it in their
supported check to completely disable themselves.
As a first step all scripted effects are considered to be unsupported
if animations are not supported. They inherit AnimationEffect and are
all about driving animations.
The information whether animations are supported comes from the Scene.
It's implemented in the following way:
* XRender: animations are always supported
* QPainter: animations are never supported
* OpenGL: animations are supported, except for software emulation
In addition - for easier testing - there is a new env variable
KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection.
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2386
All KCMs and KWin core use the BuiltInEffects namespace to find and
interact with the effects. There is no information left in the desktop
file which are of usage. Thus they can be removed.
This method replaces the X-KDE-ORDERING property in the Effect's desktop
files. This change is a preparation step for integrating the new Effect
Loader which doesn't read the ordering information. Thus it needs to be
provided by the Effect itself so that the EffectsHandler can properly
insert it into the chain.
Also for the built-in Effects on the long run it doesn't make much sense
to install the desktop files. And binary plugin effects will migrate to
json metadata which also doesn't have the KService::Ptr. Thus overall it
simplifies to read this information directly from the Effect.
Most is just switched to the ::read(). That should be enough for all the
Effects which have a KSharedConfig::Ptr underneath. If not we just need
to find a good place to put the reload.
As all effects have always been compiled into the same .so file it's
questionable whether resolving the effects through a library is useful
at all. By linking against the built-in effects we gain the following
advantages:
* don't have to load/unload the KLibrary
* don't have to resolve the create, supported and enabled functions
* no version check required
* no dependency resolving (effects don't use it)
* remove the KWIN_EFFECT macros from the effects
All the effects are now registered in an effects_builtins file which
maps the name to a factory method and supported or enabled by default
methods.
During loading the effects we first check whether there is a built-in
effect by the given name and make a shortcut to create it through that.
If that's not possible the normal plugin loading is used.
Completely unscientific testing [1] showed an improvement of almost 10
msec during loading all the effects I use.
[1] QElapsedTimer around the loading code, start kwin five times, take
average.
REVIEW: 115073
The CompositingType enum turns into flags and two new values are
introduced: OpenGL1Compositing and OpenGL2Compositing.
Those new values are or-ed to OpenGLCompositing so that a simple check
for the flag OpenGLCompositing works in case of one of those two new
values. To make the generic check for OpenGL compositing easier a method
in EffectsHandler is introduced to just check for this.
The scenes now return either OpenGL1Compositing or OpenGL2Compositing
depending on which Scene implementation. None returns OpenGLCompositing.
The supportInformation is extended to also read the properties
on all effects. In addition each effect can be queried just for
itself through D-Bus, e.g.:
qdbus org.kde.kwin /KWin supportInformationForEffect kwin4_effect_blur
All effects are extended to provide their configured and read
settings through properties. In some cases also important
runtime information is exposed.
REVIEW: 105977
BUG: 305338
FIXED-IN: 4.9.1
Effects can specify their minimum requirements in their
desktop file:
* OpenGL
* OpenGL 2 (GLSL required)
* Shaders (either ARB or OpenGL 2)
The configuration module uses this information in combination
with which backend KWin is currently using. So if e.g. OpenGL
is used and an effect requires OpenGL 2 a detailed error
message can be showed that OpenGL 2 is required.
BUG: 209213
FIXED-IN: 4.9.0
REVIEW: 104847
Each effect is able to declare itself as currently being active,
that is transforming windows or painting or screen or doing anything
during the current rendered frame.
This change eliminates the hottest path inside KWin identified by
callgrind.
REVIEW: 102449
