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:
In some cases, the out transition is false-triggered because we don't
react to changes in the keep-above and the full screen state.
Test Plan:
* Set the keep-above state on a window;
* Click on the desktop;
* (the window didn't "flicker")
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16270
Summary:
Such an option would be useful for people that are used to watch videos
in the fullscreen mode.
By default, we still dim fullscreen windows because watching videos in
fullscreen mode is not the only one use-case. One could have a text
editor in fullscreen mode on one screen and Konsole on another screen.
In that case, it would be desired to dim the text editor if the latter
is active. Also, because we don't have stats of how the fullscreen mode
is used by KDE Plasma users.
BUG: 399822
FIXED-IN: 5.15.0
Test Plan:
* Unchecked the "Fullscreen windows" checkbox;
* Opened Konsole;
* Opened Firefox in the fullscreen mode;
* Pressed Alt+Tab;
* (Firefox stayed bright)
Reviewers: #kwin, #plasma, davidedmundson
Reviewed By: #kwin, #plasma, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16216
Summary:
The Dim Inactive effect was rewritten mostly to fix most of issues with
it, e.g. after leaving a full screen effect(e.g. Desktop Grid) windows
sometimes are not dimmed back, or when a window becomes inactive there
is no smooth transition, etc.
{F5956124}
//Before: the window is not smoothly dimmed.//
{F5956127}
//After: the window is smoothly dimmed.//
In combination with an effect that animates the disappearing of windows,
e.g. Glide, the rewritten Dim Inactive effect doesn't "flash" windows.
If an active window has been closed, it will stay bright. If an inactive
window has been closed, it will stay dimmed.
Among other changes, the KCM has been re-designed to follow common KCM
design in Plasma:
{F5956128, layout=center, size=full}
The way the rewritten Dim Inactive effect handles flashing/flickering problem can be
reused in the Dialog Parent effect.
### Demo
{F5959885}
//Before: dimming of a window group.//
{F5959886}
//After: Dimming of a window group.//
Depends on D13740
CCBUG: 359251
Test Plan:
Test plan #1
* Activated the Desktop Grid effect
* Dimmed windows smoothly brightened
* Left desktop grid
* Windows dimmed back
Test plan #2
* Opened Dolphin and its Preferences window
* Clicked on desktop, both Dolphin and the Preferences window dimmed
* Clicked on Dolphin, both windows smoothly brightened back
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: davidedmundson, abetts, ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13720
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.
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
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.
EffectsHandlerImpl connects to the Workspace signal clientActivated.
The emitting of the signal is slightly moved from before the activation logic
to after the activation logic. This might change behavior in the scripting
component, but the previous code looked wrong.
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
