2020-08-02 22:22:19 +00:00
|
|
|
/*
|
|
|
|
KWin - the KDE window manager
|
|
|
|
This file is part of the KDE project.
|
2013-05-27 08:45:22 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-FileCopyrightText: 2013 Martin Gräßlin <mgraesslin@kde.org>
|
2013-05-27 08:45:22 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
*/
|
2013-05-27 08:45:22 +00:00
|
|
|
// own
|
|
|
|
#include "kscreen.h"
|
|
|
|
// KConfigSkeleton
|
|
|
|
#include "kscreenconfig.h"
|
|
|
|
|
|
|
|
/**
|
|
|
|
* How this effect works:
|
|
|
|
*
|
|
|
|
* Effect announces that it is around through property _KDE_KWIN_KSCREEN_SUPPORT on the root window.
|
|
|
|
*
|
|
|
|
* KScreen watches for this property and when it wants to adjust screens, KScreen goes
|
|
|
|
* through the following protocol:
|
|
|
|
* 1. KScreen sets the property value to 1
|
|
|
|
* 2. Effect starts to fade out all windows
|
|
|
|
* 3. When faded out the effect sets property value to 2
|
|
|
|
* 4. KScreen adjusts the screens
|
|
|
|
* 5. KScreen sets property value to 3
|
|
|
|
* 6. Effect starts to fade in all windows again
|
|
|
|
* 7. Effect sets back property value to 0
|
|
|
|
*
|
|
|
|
* The property has type 32 bits cardinal. To test it use:
|
|
|
|
* xprop -root -f _KDE_KWIN_KSCREEN_SUPPORT 32c -set _KDE_KWIN_KSCREEN_SUPPORT 1
|
|
|
|
*
|
|
|
|
* The states are:
|
|
|
|
* 0: normal
|
|
|
|
* 1: fading out
|
|
|
|
* 2: faded out
|
|
|
|
* 3: fading in
|
2019-07-29 18:58:33 +00:00
|
|
|
*/
|
2013-05-27 08:45:22 +00:00
|
|
|
|
|
|
|
namespace KWin
|
|
|
|
{
|
|
|
|
|
|
|
|
KscreenEffect::KscreenEffect()
|
|
|
|
: Effect()
|
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
|
|
|
, m_lastPresentTime(std::chrono::milliseconds::zero())
|
2013-05-27 08:45:22 +00:00
|
|
|
, m_state(StateNormal)
|
|
|
|
, m_atom(effects->announceSupportProperty("_KDE_KWIN_KSCREEN_SUPPORT", this))
|
|
|
|
{
|
2016-12-02 19:27:43 +00:00
|
|
|
initConfig<KscreenConfig>();
|
2019-01-01 20:48:53 +00:00
|
|
|
connect(effects, &EffectsHandler::propertyNotify, this, &KscreenEffect::propertyNotify);
|
2017-09-10 14:51:18 +00:00
|
|
|
connect(effects, &EffectsHandler::xcbConnectionChanged, this,
|
|
|
|
[this] {
|
|
|
|
m_atom = effects->announceSupportProperty(QByteArrayLiteral("_KDE_KWIN_KSCREEN_SUPPORT"), this);
|
|
|
|
}
|
|
|
|
);
|
2013-05-27 08:45:22 +00:00
|
|
|
reconfigure(ReconfigureAll);
|
|
|
|
}
|
|
|
|
|
|
|
|
KscreenEffect::~KscreenEffect()
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
void KscreenEffect::reconfigure(ReconfigureFlags flags)
|
|
|
|
{
|
|
|
|
Q_UNUSED(flags)
|
|
|
|
|
2014-03-25 15:29:03 +00:00
|
|
|
KscreenConfig::self()->read();
|
2018-07-03 09:56:21 +00:00
|
|
|
m_timeLine.setDuration(
|
|
|
|
std::chrono::milliseconds(animationTime<KscreenConfig>(250)));
|
2013-05-27 08:45:22 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
void KscreenEffect::prePaintScreen(ScreenPrePaintData &data, std::chrono::milliseconds presentTime)
|
2013-05-27 08:45:22 +00:00
|
|
|
{
|
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 delta = std::chrono::milliseconds::zero();
|
|
|
|
if (m_lastPresentTime.count()) {
|
|
|
|
delta = presentTime - m_lastPresentTime;
|
|
|
|
}
|
|
|
|
|
2013-05-27 08:45:22 +00:00
|
|
|
if (m_state == StateFadingIn || m_state == StateFadingOut) {
|
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
|
|
|
m_timeLine.update(delta);
|
2018-07-03 09:56:21 +00:00
|
|
|
if (m_timeLine.done()) {
|
2013-05-27 08:45:22 +00:00
|
|
|
switchState();
|
|
|
|
}
|
|
|
|
}
|
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
|
|
|
|
|
|
|
if (isActive()) {
|
|
|
|
m_lastPresentTime = presentTime;
|
|
|
|
} else {
|
|
|
|
m_lastPresentTime = std::chrono::milliseconds::zero();
|
|
|
|
}
|
|
|
|
|
|
|
|
effects->prePaintScreen(data, presentTime);
|
2013-05-27 08:45:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void KscreenEffect::postPaintScreen()
|
|
|
|
{
|
|
|
|
if (m_state == StateFadingIn || m_state == StateFadingOut) {
|
|
|
|
effects->addRepaintFull();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
void KscreenEffect::prePaintWindow(EffectWindow *w, WindowPrePaintData &data, std::chrono::milliseconds presentTime)
|
2013-05-27 08:45:22 +00:00
|
|
|
{
|
|
|
|
if (m_state != StateNormal) {
|
|
|
|
data.setTranslucent();
|
|
|
|
}
|
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
|
|
|
effects->prePaintWindow(w, data, presentTime);
|
2013-05-27 08:45:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void KscreenEffect::paintWindow(EffectWindow *w, int mask, QRegion region, WindowPaintData &data)
|
|
|
|
{
|
2018-04-24 21:20:14 +00:00
|
|
|
//fade to black and fully opaque
|
2013-05-27 08:45:22 +00:00
|
|
|
switch (m_state) {
|
2018-04-24 21:20:14 +00:00
|
|
|
case StateFadingOut:
|
2018-07-03 09:56:21 +00:00
|
|
|
data.setOpacity(data.opacity() + (1.0 - data.opacity()) * m_timeLine.value());
|
|
|
|
data.multiplyBrightness(1.0 - m_timeLine.value());
|
2018-04-24 21:20:14 +00:00
|
|
|
break;
|
|
|
|
case StateFadedOut:
|
|
|
|
data.multiplyOpacity(0.0);
|
|
|
|
data.multiplyBrightness(0.0);
|
|
|
|
break;
|
|
|
|
case StateFadingIn:
|
2018-07-03 09:56:21 +00:00
|
|
|
data.setOpacity(data.opacity() + (1.0 - data.opacity()) * (1.0 - m_timeLine.value()));
|
|
|
|
data.multiplyBrightness(m_timeLine.value());
|
2018-04-24 21:20:14 +00:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
// no adjustment
|
|
|
|
break;
|
2013-05-27 08:45:22 +00:00
|
|
|
}
|
|
|
|
effects->paintWindow(w, mask, region, data);
|
|
|
|
}
|
|
|
|
|
|
|
|
void KscreenEffect::propertyNotify(EffectWindow *window, long int atom)
|
|
|
|
{
|
2017-09-10 14:51:18 +00:00
|
|
|
if (window || atom != m_atom || m_atom == XCB_ATOM_NONE) {
|
2013-05-27 08:45:22 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
QByteArray byteData = effects->readRootProperty(m_atom, XCB_ATOM_CARDINAL, 32);
|
2015-01-17 23:51:14 +00:00
|
|
|
const uint32_t *data = byteData.isEmpty() ? nullptr : reinterpret_cast<const uint32_t *>(byteData.data());
|
2014-11-24 21:06:30 +00:00
|
|
|
if (!data // Property was deleted
|
|
|
|
|| data[0] == 0) { // normal state - KWin should have switched to it
|
2013-05-27 08:45:22 +00:00
|
|
|
if (m_state != StateNormal) {
|
|
|
|
m_state = StateNormal;
|
|
|
|
effects->addRepaintFull();
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (data[0] == 2) {
|
|
|
|
// faded out state - KWin should have switched to it
|
|
|
|
if (m_state != StateFadedOut) {
|
|
|
|
m_state = StateFadedOut;
|
|
|
|
effects->addRepaintFull();
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (data[0] == 1) {
|
|
|
|
// kscreen wants KWin to fade out all windows
|
|
|
|
m_state = StateFadingOut;
|
2018-07-03 09:56:21 +00:00
|
|
|
m_timeLine.reset();
|
2013-05-27 08:45:22 +00:00
|
|
|
effects->addRepaintFull();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (data[0] == 3) {
|
|
|
|
// kscreen wants KWin to fade in again
|
|
|
|
m_state = StateFadingIn;
|
2018-07-03 09:56:21 +00:00
|
|
|
m_timeLine.reset();
|
2013-05-27 08:45:22 +00:00
|
|
|
effects->addRepaintFull();
|
|
|
|
return;
|
|
|
|
}
|
2013-11-29 05:18:28 +00:00
|
|
|
qCDebug(KWINEFFECTS) << "Incorrect Property state, immediate stop: " << data[0];
|
2013-05-27 08:45:22 +00:00
|
|
|
m_state = StateNormal;
|
|
|
|
effects->addRepaintFull();
|
|
|
|
}
|
|
|
|
|
|
|
|
void KscreenEffect::switchState()
|
|
|
|
{
|
|
|
|
long value = -1l;
|
|
|
|
if (m_state == StateFadingOut) {
|
|
|
|
m_state = StateFadedOut;
|
|
|
|
value = 2l;
|
|
|
|
} else if (m_state == StateFadingIn) {
|
|
|
|
m_state = StateNormal;
|
|
|
|
value = 0l;
|
|
|
|
}
|
2017-09-10 14:51:18 +00:00
|
|
|
if (value != -1l && m_atom != XCB_ATOM_NONE) {
|
2014-04-16 13:58:06 +00:00
|
|
|
xcb_change_property(xcbConnection(), XCB_PROP_MODE_REPLACE, x11RootWindow(), m_atom, XCB_ATOM_CARDINAL, 32, 1, &value);
|
2013-05-27 08:45:22 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool KscreenEffect::isActive() const
|
|
|
|
{
|
|
|
|
return m_state != StateNormal;
|
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace KWin
|