Commit graph

15 commits

Author SHA1 Message Date
Vlad Zahorodnii
9f2cb0ae1b Provide expected presentation time to effects
Effects are given the interval between two consecutive frames. The main
flaw of this approach is that if the Compositor transitions from the idle
state to "active" state, i.e. when there is something to repaint,
effects may see a very large interval between the last painted frame and
the current. In order to address this issue, the Scene invalidates the
timer that is used to measure time between consecutive frames before the
Compositor is about to become idle.

While this works perfectly fine with Xinerama-style rendering, with per
screen rendering, determining whether the compositor is about to idle is
rather a tedious task mostly because a single output can't be used for
the test.

Furthermore, since the Compositor schedules pointless repaints just to
ensure that it's idle, it might take several attempts to figure out
whether the scene timer must be invalidated if you use (true) per screen
rendering.

Ideally, all effects should use a timeline helper that is aware of the
underlying render loop and its timings. However, this option is off the
table because it will involve a lot of work to implement it.

Alternative and much simpler option is to pass the expected presentation
time to effects rather than time between consecutive frames. This means
that effects are responsible for determining how much animation timelines
have to be advanced. Typically, an effect would have to store the
presentation timestamp provided in either prePaint{Screen,Window} and
use it in the subsequent prePaint{Screen,Window} call to estimate the
amount of time passed between the next and the last frames.

Unfortunately, this is an API incompatible change. However, it shouldn't
take a lot of work to port third-party binary effects, which don't use the
AnimationEffect class, to the new API. On the bright side, we no longer
need to be concerned about the Compositor getting idle.

We do still try to determine whether the Compositor is about to idle,
primarily, because the OpenGL render backend swaps buffers on present,
but that will change with the ongoing compositing timing rework.
2020-12-10 07:14:42 +00:00
Vlad Zahorodnii
4ce853e8e4 Prettify license headers 2020-08-07 19:57:56 +00:00
Vlad Zahorodnii
1fb9f6f13a Switch to SPDX license markers
The main advantage of SPDX license identifiers over the traditional
license headers is that it's more difficult to overlook inappropriate
licenses for kwin, for example GPL 3. We also don't have to copy a
lot of boilerplate text.

In order to create this change, I ran licensedigger -r -c from the
toplevel source directory.
2020-08-07 19:57:56 +00:00
Vlad Zagorodniy
8af2fa73dc Run clang-tidy with modernize-use-override check
Summary:
Currently code base of kwin can be viewed as two pieces. One is very
ancient, and the other one is more modern, which uses new C++ features.

The main problem with the ancient code is that it was written before
C++11 era. So, no override or final keywords, lambdas, etc.

Quite recently, KDE compiler settings were changed to show a warning if
a virtual method has missing override keyword. As you might have already
guessed, this fired back at us because of that ancient code. We had
about 500 new compiler warnings.

A "solution" was proposed to that problem - disable -Wno-suggest-override
and the other similar warning for clang. It's hard to call a solution
because those warnings are disabled not only for the old code, but also
for new. This is not what we want!

The main argument for not actually fixing the problem was that git
history will be screwed as well because of human factor. While good git
history is a very important thing, we should not go crazy about it and
block every change that somehow alters git history. git blame allows to
specify starting revision for a reason.

The other argument (human factor) can be easily solved by using tools
such as clang-tidy. clang-tidy is a clang-based linter for C++. It can
be used for various things, e.g. fixing coding style(e.g. add missing
braces to if statements, readability-braces-around-statements check),
or in our case add missing override keywords.

Test Plan: Compiles.

Reviewers: #kwin, davidedmundson

Reviewed By: #kwin, davidedmundson

Subscribers: davidedmundson, apol, romangg, kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 20:03:22 +03:00
Vlad Zagorodniy
5daa612bce [effects/fallapart] Fix flickering problem
Summary:
The Fall Apart effect doesn't grab windows so a conflict could happen
if an alternative window open/close animation effect is enabled(e.g.
Fade, Glide).

### Before

{F5912324}

//Fall apart and Fade conflict with each other.//

### After

{F5912325}

//Only Fall apart animates the disappearing of System Settings.//

Test Plan:
* Enabled fall apart effect and fade effect
* Closed a window

Reviewers: #kwin, davidedmundson

Reviewed By: #kwin, davidedmundson

Subscribers: kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D13527
2018-06-14 13:22:58 +03:00
Martin Gräßlin
3bbc9436db [kwin] Add a virtual Effect::requestedEffectChainPosition
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.
2014-03-28 14:04:54 +01:00
Martin Gräßlin
d3ba02fa42 FallApart effect requires OpenGL
It does quad transformations which is only supported in the OpenGL
compositor.

REVIEW: 111176
2013-06-23 11:52:34 +02:00
Martin Gräßlin
23f2de009b Effects can provide support information through properties
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
2012-08-17 17:49:49 +02:00
Martin Gräßlin
2007a7eab8 Use namespaced parameters in signals
Required to get scripting bindings working.
2012-03-12 21:37:40 +01:00
Martin Gräßlin
fe4329a252 Only call active effects in the effect chain
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
2011-08-29 07:06:58 +02:00
Martin Gräßlin
e355700e6e EffectsHandler emits windowDeleted signal
Workspace emits a deletedRemoved signal which the EffectsHandlerImpl translates
into a windowDeleted signal.
2011-02-27 10:47:42 +01:00
Martin Gräßlin
0b85768ec5 EffectsHandler emits windowClosed signal
Client and Unmanaged use a signal to notify that they are about to be closed.
The EffectsHandlerImpl is connected to those signals and emits the appropriate
windowClosed signal to which the effects are connected.
2011-02-27 09:25:45 +01:00
Martin Gräßlin
0a7e48f7aa KWin uses kdelibs coding style. 2011-01-31 20:07:03 +01:00
Luboš Luňák
117633d40d config option to specify size of blocks to fall apart to
svn path=/trunk/KDE/kdebase/workspace/; revision=1172706
2010-09-07 21:52:51 +00:00
Lucas Murray
846496d2c1 Cleaned up the effects/ directory by moving each individual effect into
its own directory, cleaned up the effect config macros and renamed
"MakeTransparent" to "Translucency" so that it matches its visible name.

svn path=/trunk/KDE/kdebase/workspace/; revision=921749
2009-02-05 15:35:38 +00:00
Renamed from effects/fallapart.h (Browse further)