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.
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.
Summary:
Won't make things go much faster since everything that was
being passed by value is refcounted but still const & is a bit faster
than refcounting
For shared pointers instead of adding const & we move them into the
destination variable saving some cpu usage but at the same time making
clear the pointer is being stored by not being const &
Reviewers: zzag
Reviewed By: zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25022
Summary:
The "Force" part in WindowForceBackgroundContrastRole and WindowForceBlurRole
is confusing. If WindowForceBlurRole is set on a window, background
behind it won't be blurred.
By setting WindowForceBlurRole we tell the Blur effect "that's fine to
do your business behind transformed windows."
The Slide effect only translates windows, it doesn't distort them, etc.
So, we can set WindowForceBackgroundContrastRole and WindowForceBlurRole
for all windows.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15707
Summary:
Kdelibs coding style states the following about whitespace placement:
> For pointers or references, use a single space before '*' or '&', but not after
Source: https://community.kde.org/Policies/Kdelibs_Coding_Style#Whitespace
Also, putting a whitespace after ! is not common in KWin.
Test Plan: Switched between virtual desktops.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14260
Summary: That's mostly to analyze what options people use in bug reports.
Test Plan:
* Enabled the Slide effect
* Ran `qdbus org.kde.KWin /KWin supportInformation`
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13843
Summary:
Some people may not like the sliding of desktop background. Add
corresponding option to disable the sliding of desktop background.
By disabling the sliding of desktop background and docks, one can
get old slide effect.
{F5912713, layout=center, size=full}
Test Plan:
* Unchecked "Slide desktop background" checkbox, switched desktop;
* Checked "Slide desktop background" checkbox, switched desktop.
Reviewers: #kwin, #plasma, #vdg, mart
Reviewed By: #kwin, #plasma, #vdg, mart
Subscribers: romangg, abetts, ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13542
Summary:
The new slide effect tries to separate each virtual desktop
as much as possible. This separation makes the new slide
effect more intuitive than the old one.
Test Plan:
* switch between virtual desktops
* or, move a window to another virtual desktop
Reviewers: #vdg, #kwin, #plasma, graesslin, ngraham
Reviewed By: #kwin, #plasma, graesslin
Subscribers: mart, graesslin, abetts, ngraham, plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D9638
Summary:
Currently, slide effect doesn't handle a case when there
is a moving client. This results in having window jumps.
This commit fixes it by fixing position of the moving client
during switching to another desktop.
Test Plan: * send window one desktop to the left/right using shortcuts
Reviewers: #kwin, #plasma, graesslin
Reviewed By: #kwin, #plasma, graesslin
Subscribers: graesslin, plasma-devel, kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9487
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.
Without setting the property, Plasma's panel and dialogs lose the
backgroundcontrast effect during slides, which makes them flicker.
As the panel is shown on screen all the time, this is quite a visible
bug. To fix this, when the slide effect is started, we check for window
types and properties of each window, and force the blur flag on if it's
unset.
If the background contrast flag is set to false, we leave the window
alone assuming that there's a reason to force it off. Windows that
are newly added during the slide get the same treatment, so something
popping up while sliding (such as the desktop switch OSD) also gets
the background effect applied.When the effect stops or is interupted, we
unset what we've set, and clean up our internal bookkeeping.
Thanks Martin and Thomas for the thorough review!
REVIEW:115857
The windows, that are considered to be always on top and that are on
all desktops, should also be always painted on top of everything while
switching the desktop.
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
The KWin::TimeLine class was only a small wrapper around QTimeLine
without adding anything to QTimeLine what is not present in QTimeLine.
The initial idea was to make it possible to provide more curve shapes.
This is now obsoleted by Qt shipping more useful curves with QTimeLine.
So let's clean up a little bit and use QTimeLine directly instead of
the small wrapper.
All effects are adjusted to use QTimeLine directly.
The first signal used between EffectsHandler and Effects.
The signal is actually emitted by the EffectsHandlerImpl and only
the interested effects connect to this signal.
EffectsHandlerImpl itself is also notified by a signal from Workspace,
allowing to remove one of the many if (effects) checks.
all code that used calcDesktopLayout() so the function could be removed.
Minor changes to the DesktopLayout class itself.
svn path=/trunk/KDE/kdebase/workspace/; revision=925930
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
