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.
This reverts commit 9d4c8fda09.
Unlike other effects this wasn't using hide/show as a hack for not
having a created/destroyed signal but because the window is internally
hidden when it's in auto-hide mode despite being still mapped.
BUG: 426686
The region that we pass to the next paintWindow() cannot be larger than
the one that we've received. If an effect passes a larger region, the
tracked buffer damage will be messed up and user will see all sorts of
visual artifacts.
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.
windowShown and windowHidden are emitted when the window becomes visible
and hidden, respectively. For example, that can be the case when the
window has been minimized or unminimized. We have to start animations
only when windowAdded or windowClosed has been emitted.
Summary:
Given that slide in/out animation duration is not initialized when slide
location is NoEdge, assert statement will be triggered in slideIn().
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23564
Summary:
KWindowSystem provides a plugin interface to have platform specific
implementations. So far KWin relied on the implementation in
KWayland-integration repository.
This is something I find unsuited, for the following reasons:
* any test in KWin for functionality set through the plugin would fail
* it's not clear what's going on where
* in worst case some code could deadlock
* KWin shouldn't use KWindowSystem and only a small subset is allowed
to be used
The last point needs some further explanation. KWin internally does not
and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is
exposing information which KWin sets. It's more than weird if KWin asks
KWindowSystem for the state of a window it set itself. On X11 it's just
slow, on Wayland it can result in roundtrips to KWin itself which is
dangerous.
But due to using Plasma components we have a few areas where we use
KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in
direction, blur and background contrast. This we want to support and
need to support. Other API elements we do not want, like for examples
the available windows. KWin internal windows either have direct access
to KWin or a scripting interface exposed providing (limited) access -
there is just no need to have this in KWindowSystem.
To make it more clear what KWin supports as API of KWindowSystem for
internal windows this change implements a stripped down version of the
kwayland-integration plugin. The main difference is that it does not use
KWayland at all, but a QWindow internal side channel.
To support this EffectWindow provides an accessor for internalWindow and
the three already mentioned effects are adjusted to read from the
internal QWindow and it's dynamic properties.
This change is a first step for a further refactoring. I plan to split
the internal window out of ShellClient into a dedicated class. I think
there are nowadays too many special cases. If it moves out there is the
question whether we really want to use Wayland for the internal windows
or whether this is just historic ballast (after all we used to use
qwayland for that in the beginning).
As the change could introduce regressions I'm targetting 5.16.
Test Plan:
new test case for window type, manual testing using Alt+Tab
for the effects integration. Sliding popups, blur and contrast worked fine.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18228
Summary:
If a window is not on the current virtual desktop, then it won't be
painted/slided. Thus, we can replace EffectWindow::desktop by
EffectsHandler::currentDesktop.
Test Plan: The effect still works correctly on both X11 and Wayland.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17944
Summary:
If you switch virtual desktops while krunner is sliding in, then
depending on whether your distro strips assert statements away,
KWin can crash.
The reason why it crashes is the sliding popups effect tries to unref
deleted windows that it hasn't referenced before (if there is an active
full screen effect, then popups won't be slided out, which in its turn
means that we won't reference deleted windows). So, in the end, the
refcount of those windows can be -1. That triggers an assert statement
in the destructor of the Deleted class, which checks whether the
refcount is equal to 0.
Popups are not slided while there is an active full screen effect because
we don't know what the full screen effect does.
This patch adjusts the sliding popups effect so it stops all active
animations when user switches virtual desktops or when a full screen
effect kicks in. We need to do that so the effect won't try to
unreference windows in postPaintWindow.
Visually, it doesn't look quite nice, but for now that's good enough.
A proper fix would be more complex: we would need to make sure that
full screen effects ignore sliding popups (and also maybe docks) and
perform some input redirection.
BUG: 400170
FIXED-IN: 5.14.4
Test Plan: I'm not able anymore to reproduce bug 400170.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: davidedmundson, graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16731
Summary:
If a window is being slided in and for some reason it gets closed, the
window will be slided out. The problem is that there is a jump between
the slide in animation and the slide out animation.
The reason for that is we cancel the slide in animation when the slide
out animation is started.
It makes sense to cancel previously active animations because they have
different durations. But visually, it doesn't look good.
TimeLine tries to preserve progress value when changing duration. Thus,
let's utilize that to fix the jump.
This change matters only with animation speed factor > 1.0.
CCBUG: 264276
Test Plan: Manually.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15626
Summary:
Full window repaints issued by the Sliding Popups effect can hide bugs in
other effects that animate the disappearing of windows (e.g. Scale).
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15822
Summary:
* Slightly improve readability;
* Check that offset and location have been passed;
* Sanitize slide in/out duration (if any of those is equal to 0, KWin
will crash).
Test Plan:
* Launched Yakuake;
* Pressed F12 several times (Yakuake still slides in/out).
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14862
Test Plan: Compiles and the Application Launcher is still sliding.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14823
Summary:
The existing Data struct has some serious problems:
(a) naming is not intuitive, SlideInterface uses more cleaner terminology
so let's use that (and because Wayland is the future);
(b) fadeInTime and fadeOutTime should be slideInDuration and slideOutDuration
respectively. The Sliding popups effect doesn't fade windows, it slides
them;
(c) mWindowsData should be m_animationsData because other parts of this
effect refer to it as "anim data"(e.g. setupAnimData).
This effect uses its own Location enum class instead of KWayland::
Server::SlideInterface::Location because it would be better to not
depend on platform specific data structures.
As a side effect, this change also fixes QHash abuse. The Sliding popups
effect is still hashing windows twice in prePaintWindow and paintWindow.
But I think that's acceptable because usually there would be only one
active sliding window.
CCBUG: 331118
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14301
Summary:
Slided popups are clipped twice:
* first, when filtering window quads in prePaintWindow;
* then, when doing scissor test (the opengl scene plugin does scissor
test for transformed windows).
Because of that, we don't need to filter window quads. Filtering window
quads only adds overhead.
This change simplifies code and "fixes" incorrect clipping when a slided
popup has shadows.
Test Plan:
* Put Plasma panel on the left screen edge;
* Open and close the Application Launcher.
(repeat for top/right/bottom screen edge)
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14450
Summary:
In addition to porting to TimeLine, this change also fixes quadratic
scaling of animation durations:
```lang=cpp
animData.fadeInDuration = animationTime(mFadeInTime);
animData.fadeOutDuration = animationTime(mFadeOutTime);
```
where
```lang=cpp
mFadeInTime = animationTime(...);
mFadeOutTime = animationTime(...);
```
Depends on D13740
Test Plan: Opened/closed Kickoff.
Reviewers: #kwin, mart
Reviewed By: #kwin, mart
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13801
Summary:
WindowBackgroundContrastRole property is a bool or undefined.
QVariant::isValid() returns true for QVariant(false) which is not what
we want for this code.
toBool on an invalid QVariant will return false.
Test Plan:
NA. Was based on code review.
To get a bug you'd have to PresentWindows/Slide effect manipulate a sliding popup, which
AFAIK doesn't happen.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13478
Summary: Fixes the build with D8705
Test Plan: Just adds includes, I wonder if it should go into Plasma/5.8 and /5.11 too
Reviewers: #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: graesslin, plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8706
Summary:
Several effects announce a support property atom on the root window. This
change forwards the KWin::Application's signal that the xcbConnection
changed to the EffectsHandler so that the effects can respond to it.
All effects which announce a support property connect to this new signal
and re-announce the property. In case the xcb connection died (future
XWayland crashing case) it is set to XCB_ATOM_NONE by that. In case the
xcb connection got created (future delayed XWayland startup) the atom is
set to the proper value.
In addition all usages of the support properties are guarded, so that no
nonesense actions are performed if the support property is XCB_ATOM_NONE.
Test Plan: Only compile tested as we don't have XFree KWin yet
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7761
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:
The effect unset the WindowClosedGrabRole unconditionally if it does not
manage the window. This results in any grab set by other effects to break.
BUG: 376609
FIXED-IN: 5.9.5
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5225
Summary:
When windows get added some effects grab the window and want to be the
only one animating this window. For this the grab roles exists. An
effect being notified later on evaluates the grab state and does not
start the animation.
This process failed due to being dependent on the order the effects are
loaded. Window Added/Closed are signals emitted by EffectsHandler, thus
first come, first serve. The requested effect order does not play into
it.
Due to that it could happen that an Effect which should not animate,
started to animate as the grab was still there.
This change adds the possibility to be notified whenever the window data
changes. A new signal is added to EffectsHandler which is emitted
whenever the windowData changes. The interested effects connect to it
and cancel their (just started) animation for the window.
Adjusted effects are:
* ScaleIn
* Fade
* WobblyWindows
In case of WobblyWindows an additional logical error was fixed that the
animations were only run when an effect grabbed instead of the other way
around.
BUG: 336866
FIXED-IN: 5.8.4
Reviewers: #kwin, #plasma, broulik
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3211
Summary:
With this change SlidingPopups is able to animate Wayland clients
properly, though windowHidden does not yet work for OpenGL based
windows (buffer seems to get lost somewhere).
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2085
In addition it's required to keep the expandedGeometry alive until
the effects handled the deletion
BUG: 318322
BUG: 320892
BUG: 344359
REVIEW: 126323
FIXED-IN: 5.6
If the property changes the animation data is updated. As the last
property change event will definately be delivered before an unmap notify
we can be sure that the animation data is up to data. Reading the
property again does not have any advantages.
By removing it we get rid of at least one roundtrip to the X Server and
it fixes one failed GetProperty error when it tries to read the property
for an already destroyed unmanaged.
REVIEW: 117431
This seems like a more proper fix for the flickering issue in the
sliding popups effect. The problem is that slidingpopups grabs the
window in windowClosed, the fade effect checks it there, which makes
it racy.
In my tests, I've not seen this problem with the WindowAddedGrab, but
as far as I understand, the problem may well be present there as well.
(And my proposed trick doesn't work.) I've not seen this happening in my
debugging, however. The problem there is also less visible since the
transparency curves go into the same direction, and are more "in line
with each other".
So, fix: Move the setData(WindowClosedGrabRole, ...) call from
windowClosed into windowAdded, which makes sure it's set whenever the
window goes away.
REVIEW:115903
BUG:329991
