2020-08-02 22:22:19 +00:00
|
|
|
/*
|
|
|
|
|
KWin - the KDE window manager
|
|
|
|
|
This file is part of the KDE project.
|
2011-10-19 23:04:52 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-FileCopyrightText: 2011 Thomas Lübking <thomas.luebking@web.de>
|
|
|
|
|
SPDX-FileCopyrightText: 2018 Vlad Zahorodnii <vlad.zahorodnii@kde.org>
|
2011-10-19 23:04:52 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
|
*/
|
2011-10-19 23:04:52 +00:00
|
|
|
|
|
|
|
|
#ifndef ANIDATA_H
|
|
|
|
|
#define ANIDATA_H
|
|
|
|
|
|
|
|
|
|
#include "kwinanimationeffect.h"
|
2018-10-23 15:21:51 +00:00
|
|
|
|
2011-10-19 23:04:52 +00:00
|
|
|
#include <QEasingCurve>
|
|
|
|
|
|
|
|
|
|
namespace KWin {
|
|
|
|
|
|
2018-10-09 15:44:07 +00:00
|
|
|
/**
|
|
|
|
|
* Wraps effects->setActiveFullScreenEffect for the duration of it's lifespan
|
2019-07-29 18:58:33 +00:00
|
|
|
*/
|
2018-10-09 15:44:07 +00:00
|
|
|
class FullScreenEffectLock
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
FullScreenEffectLock(Effect *effect);
|
|
|
|
|
~FullScreenEffectLock();
|
|
|
|
|
private:
|
|
|
|
|
Q_DISABLE_COPY(FullScreenEffectLock)
|
|
|
|
|
};
|
|
|
|
|
typedef QSharedPointer<FullScreenEffectLock> FullScreenEffectLockPtr;
|
|
|
|
|
|
[effects/dialogparent] Fix flickering of parent windows
Summary:
If a modal window is closed and some alternative effect that animates
the disappearing of windows is enabled(e.g. the Glide effect, or the
Scale effect), the Dialog Parent effect can cause flickering of the
parent window because its animation duration doesn't match duration of
those alternative effects.
Also, if the Fade effect, the Glide effect, and the Scale effect are
disabled, the Dialog Parent will keep the parent window alive for no
good reason.
This change addresses that problem by adding keepAlive property to
`animate` function so scripted effects have more control over lifetime
of animated windows.
If both a modal window and its parent window are closed at the same time
(and there is no effect that animates the disappearing of windows), the
Dialog Parent will stop immediately(because windowDeleted will be
emitted right after windowClosed signal).
If both a modal window and its parent window are closed at the same time
(and there is effect that animates the disappearing of windows), the
Dialog Parent won't reference the latter window. Thus, it won't cause
flickering. I.e. it will "passively" animate parent windows.
BUG: 355036
FIXED-IN: 5.15.0
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14919
2018-10-10 07:36:45 +00:00
|
|
|
/**
|
|
|
|
|
* Keeps windows alive during animation after they got closed
|
2019-07-29 18:58:33 +00:00
|
|
|
*/
|
[effects/dialogparent] Fix flickering of parent windows
Summary:
If a modal window is closed and some alternative effect that animates
the disappearing of windows is enabled(e.g. the Glide effect, or the
Scale effect), the Dialog Parent effect can cause flickering of the
parent window because its animation duration doesn't match duration of
those alternative effects.
Also, if the Fade effect, the Glide effect, and the Scale effect are
disabled, the Dialog Parent will keep the parent window alive for no
good reason.
This change addresses that problem by adding keepAlive property to
`animate` function so scripted effects have more control over lifetime
of animated windows.
If both a modal window and its parent window are closed at the same time
(and there is no effect that animates the disappearing of windows), the
Dialog Parent will stop immediately(because windowDeleted will be
emitted right after windowClosed signal).
If both a modal window and its parent window are closed at the same time
(and there is effect that animates the disappearing of windows), the
Dialog Parent won't reference the latter window. Thus, it won't cause
flickering. I.e. it will "passively" animate parent windows.
BUG: 355036
FIXED-IN: 5.15.0
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14919
2018-10-10 07:36:45 +00:00
|
|
|
class KeepAliveLock
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
KeepAliveLock(EffectWindow *w);
|
|
|
|
|
~KeepAliveLock();
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
EffectWindow *m_window;
|
|
|
|
|
Q_DISABLE_COPY(KeepAliveLock)
|
|
|
|
|
};
|
|
|
|
|
typedef QSharedPointer<KeepAliveLock> KeepAliveLockPtr;
|
|
|
|
|
|
2018-10-23 17:21:27 +00:00
|
|
|
/**
|
|
|
|
|
* References the previous window pixmap to prevent discarding.
|
2019-07-29 18:58:33 +00:00
|
|
|
*/
|
2018-10-23 17:21:27 +00:00
|
|
|
class PreviousWindowPixmapLock
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
PreviousWindowPixmapLock(EffectWindow *w);
|
|
|
|
|
~PreviousWindowPixmapLock();
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
EffectWindow *m_window;
|
|
|
|
|
Q_DISABLE_COPY(PreviousWindowPixmapLock)
|
|
|
|
|
};
|
|
|
|
|
typedef QSharedPointer<PreviousWindowPixmapLock> PreviousWindowPixmapLockPtr;
|
|
|
|
|
|
2018-07-23 21:52:58 +00:00
|
|
|
class KWINEFFECTS_EXPORT AniData {
|
2011-10-19 23:04:52 +00:00
|
|
|
public:
|
|
|
|
|
AniData();
|
2018-10-24 16:39:37 +00:00
|
|
|
AniData(AnimationEffect::Attribute a, int meta, const FPx2 &to,
|
|
|
|
|
int delay, const FPx2 &from, bool waitAtSource,
|
2019-10-29 22:04:15 +00:00
|
|
|
FullScreenEffectLockPtr =FullScreenEffectLockPtr(),
|
2018-10-23 17:21:27 +00:00
|
|
|
bool keepAlive = true, PreviousWindowPixmapLockPtr previousWindowPixmapLock = {});
|
2018-10-24 16:39:37 +00:00
|
|
|
|
[scripting] Introduce redirect function
Summary:
Consider current implementation of the Squash effect: if a window was
minimized, an animation will be started; if the window is unminimized
and the animation is still active (that can happen when user clicks on
app's icon really fast), the animation will be stopped and a new one will
be created. Such behavior can lead to rapid jumps in the observed
"animation".
A better approach would be first try to **reverse** the already active
animation, and if that attempt wasn't successful, start a new animation.
This patch introduces a new function to the scripted effects API that
lets JavaScript effects to control direction of animations. The
prototype of the function looks as follows:
redirect(<animation id(s)>, <direction>, [<termination policy>])
the first argument is an animation id or a list of animation ids, the
second argument specifies the new direction of the animation or
animations if a list of ids was passed as the first argument. The
third argument specifies whether the animation(s) should be terminated
when it(they) reaches the source position, currently it's relevant only
for animations that are created with set() function. The termination
policy argument is optional, by default it's Effect.TerminateAtSource.
We can use this function to fix issues with rapid jumps in the Squash
effect. Also, redirect() lets us to write effects for simple animations
in slightly different style: first, we have to start the main animation
(e.g. for the Dialog Parent effect, it would be dimming of main windows)
and then change direction of the animation depending on external events,
e.g. when the Desktop Cube effect is activated.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16449
2018-10-24 19:58:29 +00:00
|
|
|
bool isActive() const;
|
|
|
|
|
|
2011-10-19 23:04:52 +00:00
|
|
|
inline bool isOneDimensional() const {
|
|
|
|
|
return from[0] == from[1] && to[0] == to[1];
|
|
|
|
|
}
|
2016-03-04 17:17:42 +00:00
|
|
|
|
|
|
|
|
quint64 id{0};
|
2012-10-27 21:35:19 +00:00
|
|
|
QString debugInfo() const;
|
2011-10-19 23:04:52 +00:00
|
|
|
AnimationEffect::Attribute attribute;
|
|
|
|
|
int customCurve;
|
|
|
|
|
FPx2 from, to;
|
2018-10-24 16:39:37 +00:00
|
|
|
TimeLine timeLine;
|
2011-10-19 23:04:52 +00:00
|
|
|
uint meta;
|
2012-11-03 20:33:34 +00:00
|
|
|
qint64 startTime;
|
2018-10-03 00:11:59 +00:00
|
|
|
QSharedPointer<FullScreenEffectLock> fullScreenEffectLock;
|
[scripting] Introduce redirect function
Summary:
Consider current implementation of the Squash effect: if a window was
minimized, an animation will be started; if the window is unminimized
and the animation is still active (that can happen when user clicks on
app's icon really fast), the animation will be stopped and a new one will
be created. Such behavior can lead to rapid jumps in the observed
"animation".
A better approach would be first try to **reverse** the already active
animation, and if that attempt wasn't successful, start a new animation.
This patch introduces a new function to the scripted effects API that
lets JavaScript effects to control direction of animations. The
prototype of the function looks as follows:
redirect(<animation id(s)>, <direction>, [<termination policy>])
the first argument is an animation id or a list of animation ids, the
second argument specifies the new direction of the animation or
animations if a list of ids was passed as the first argument. The
third argument specifies whether the animation(s) should be terminated
when it(they) reaches the source position, currently it's relevant only
for animations that are created with set() function. The termination
policy argument is optional, by default it's Effect.TerminateAtSource.
We can use this function to fix issues with rapid jumps in the Squash
effect. Also, redirect() lets us to write effects for simple animations
in slightly different style: first, we have to start the main animation
(e.g. for the Dialog Parent effect, it would be dimming of main windows)
and then change direction of the animation depending on external events,
e.g. when the Desktop Cube effect is activated.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16449
2018-10-24 19:58:29 +00:00
|
|
|
bool waitAtSource;
|
[effects/dialogparent] Fix flickering of parent windows
Summary:
If a modal window is closed and some alternative effect that animates
the disappearing of windows is enabled(e.g. the Glide effect, or the
Scale effect), the Dialog Parent effect can cause flickering of the
parent window because its animation duration doesn't match duration of
those alternative effects.
Also, if the Fade effect, the Glide effect, and the Scale effect are
disabled, the Dialog Parent will keep the parent window alive for no
good reason.
This change addresses that problem by adding keepAlive property to
`animate` function so scripted effects have more control over lifetime
of animated windows.
If both a modal window and its parent window are closed at the same time
(and there is no effect that animates the disappearing of windows), the
Dialog Parent will stop immediately(because windowDeleted will be
emitted right after windowClosed signal).
If both a modal window and its parent window are closed at the same time
(and there is effect that animates the disappearing of windows), the
Dialog Parent won't reference the latter window. Thus, it won't cause
flickering. I.e. it will "passively" animate parent windows.
BUG: 355036
FIXED-IN: 5.15.0
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14919
2018-10-10 07:36:45 +00:00
|
|
|
bool keepAlive;
|
|
|
|
|
KeepAliveLockPtr keepAliveLock;
|
2018-10-23 17:21:27 +00:00
|
|
|
PreviousWindowPixmapLockPtr previousWindowPixmapLock;
|
[scripting] Introduce redirect function
Summary:
Consider current implementation of the Squash effect: if a window was
minimized, an animation will be started; if the window is unminimized
and the animation is still active (that can happen when user clicks on
app's icon really fast), the animation will be stopped and a new one will
be created. Such behavior can lead to rapid jumps in the observed
"animation".
A better approach would be first try to **reverse** the already active
animation, and if that attempt wasn't successful, start a new animation.
This patch introduces a new function to the scripted effects API that
lets JavaScript effects to control direction of animations. The
prototype of the function looks as follows:
redirect(<animation id(s)>, <direction>, [<termination policy>])
the first argument is an animation id or a list of animation ids, the
second argument specifies the new direction of the animation or
animations if a list of ids was passed as the first argument. The
third argument specifies whether the animation(s) should be terminated
when it(they) reaches the source position, currently it's relevant only
for animations that are created with set() function. The termination
policy argument is optional, by default it's Effect.TerminateAtSource.
We can use this function to fix issues with rapid jumps in the Squash
effect. Also, redirect() lets us to write effects for simple animations
in slightly different style: first, we have to start the main animation
(e.g. for the Dialog Parent effect, it would be dimming of main windows)
and then change direction of the animation depending on external events,
e.g. when the Desktop Cube effect is activated.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16449
2018-10-24 19:58:29 +00:00
|
|
|
AnimationEffect::TerminationFlags terminationFlags;
|
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-11-20 15:44:04 +00:00
|
|
|
std::chrono::milliseconds lastPresentTime;
|
2011-10-19 23:04:52 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
} // namespace
|
|
|
|
|
|
2012-10-27 21:35:19 +00:00
|
|
|
QDebug operator<<(QDebug dbg, const KWin::AniData &a);
|
|
|
|
|
|
2011-10-19 23:04:52 +00:00
|
|
|
#endif // ANIDATA_H
|
