2020-08-02 22:22:19 +00:00
|
|
|
/*
|
|
|
|
|
KWin - the KDE window manager
|
|
|
|
|
This file is part of the KDE project.
|
2009-01-31 15:12:14 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-FileCopyrightText: 2009 Lucas Murray <lmurray@undefinedfire.com>
|
2009-01-31 15:12:14 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
|
*/
|
2009-01-31 15:12:14 +00:00
|
|
|
|
|
|
|
|
#include "highlightwindow.h"
|
|
|
|
|
|
|
|
|
|
namespace KWin
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
HighlightWindowEffect::HighlightWindowEffect()
|
2011-01-30 14:34:42 +00:00
|
|
|
: m_finishing(false)
|
2011-12-13 13:28:20 +00:00
|
|
|
, m_fadeDuration(float(animationTime(150)))
|
Use nullptr everywhere
Summary:
Because KWin is a very old project, we use three kinds of null pointer
literals: 0, NULL, and nullptr. Since C++11, it's recommended to use
nullptr keyword.
This change converts all usages of 0 and NULL literal to nullptr. Even
though it breaks git history, we need to do it in order to have consistent
code as well to ease code reviews (it's very tempting for some people to
add unrelated changes to their patches, e.g. converting NULL to nullptr).
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, davidedmundson, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23618
2019-09-19 14:46:54 +00:00
|
|
|
, m_monitorWindow(nullptr)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2012-12-13 23:09:47 +00:00
|
|
|
m_atom = effects->announceSupportProperty("_KDE_WINDOW_HIGHLIGHT", this);
|
2019-01-01 20:48:53 +00:00
|
|
|
connect(effects, &EffectsHandler::windowAdded, this, &HighlightWindowEffect::slotWindowAdded);
|
|
|
|
|
connect(effects, &EffectsHandler::windowClosed, this, &HighlightWindowEffect::slotWindowClosed);
|
|
|
|
|
connect(effects, &EffectsHandler::windowDeleted, this, &HighlightWindowEffect::slotWindowDeleted);
|
|
|
|
|
connect(effects, &EffectsHandler::propertyNotify, this,
|
|
|
|
|
[this](EffectWindow *w, long atom) {
|
|
|
|
|
slotPropertyNotify(w, atom, nullptr);
|
|
|
|
|
}
|
|
|
|
|
);
|
2017-09-10 14:51:18 +00:00
|
|
|
connect(effects, &EffectsHandler::xcbConnectionChanged, this,
|
|
|
|
|
[this] {
|
|
|
|
|
m_atom = effects->announceSupportProperty("_KDE_WINDOW_HIGHLIGHT", this);
|
|
|
|
|
}
|
|
|
|
|
);
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2009-01-31 15:12:14 +00:00
|
|
|
|
|
|
|
|
HighlightWindowEffect::~HighlightWindowEffect()
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
|
|
|
|
}
|
2009-01-31 15:12:14 +00:00
|
|
|
|
2011-01-30 14:34:42 +00:00
|
|
|
static bool isInitiallyHidden(EffectWindow* w)
|
|
|
|
|
{
|
|
|
|
|
// Is the window initially hidden until it is highlighted?
|
2019-09-14 08:58:12 +00:00
|
|
|
return w->isMinimized() || !w->isOnCurrentDesktop();
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2009-12-20 12:48:54 +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 HighlightWindowEffect::prePaintWindow(EffectWindow* w, WindowPrePaintData& data, std::chrono::milliseconds presentTime)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2009-02-03 10:51:36 +00:00
|
|
|
// Calculate window opacities
|
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
|
|
|
QHash<EffectWindow*, HightlightWindowData>::iterator it = m_animations.find(w);
|
2011-01-30 14:34:42 +00:00
|
|
|
if (!m_highlightedWindows.isEmpty()) {
|
|
|
|
|
// Initial fade out and changing highlight animation
|
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 (it == m_animations.end())
|
|
|
|
|
it = m_animations.insert(w, HightlightWindowData());
|
|
|
|
|
|
|
|
|
|
int time = 1;
|
|
|
|
|
if (it->lastPresentTime.count()) {
|
|
|
|
|
time = std::max(1, int((presentTime - it->lastPresentTime).count()));
|
|
|
|
|
}
|
|
|
|
|
it->lastPresentTime = presentTime;
|
|
|
|
|
|
|
|
|
|
float oldOpacity = it->opacity;
|
2011-01-30 14:34:42 +00:00
|
|
|
if (m_highlightedWindows.contains(w))
|
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
|
|
|
it->opacity = qMin(1.0f, oldOpacity + time / m_fadeDuration);
|
2011-01-30 14:34:42 +00:00
|
|
|
else if (w->isNormalWindow() || w->isDialog()) // Only fade out windows
|
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
|
|
|
it->opacity = qMax(isInitiallyHidden(w) ? 0.0f : 0.15f, oldOpacity - time / m_fadeDuration);
|
2009-02-03 10:51:36 +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
|
|
|
if (it->opacity < 0.98f)
|
2009-02-03 10:51:36 +00:00
|
|
|
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
|
|
|
if (oldOpacity != it->opacity)
|
2016-09-12 09:13:11 +00:00
|
|
|
effects->addRepaint(w->expandedGeometry());
|
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
|
|
|
} else if (m_finishing && m_animations.contains(w)) {
|
2011-01-30 14:34:42 +00:00
|
|
|
// Final fading back in animation
|
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 (it == m_animations.end())
|
|
|
|
|
it = m_animations.insert(w, HightlightWindowData());
|
|
|
|
|
|
|
|
|
|
int time = 1;
|
|
|
|
|
if (it->lastPresentTime.count()) {
|
|
|
|
|
time = std::max(1, int((presentTime - it->lastPresentTime).count()));
|
|
|
|
|
}
|
|
|
|
|
it->lastPresentTime = presentTime;
|
|
|
|
|
|
|
|
|
|
float oldOpacity = it->opacity;
|
2011-01-30 14:34:42 +00:00
|
|
|
if (isInitiallyHidden(w))
|
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
|
|
|
it->opacity = qMax(0.0f, oldOpacity - time / m_fadeDuration);
|
2009-12-20 12:48:54 +00:00
|
|
|
else
|
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
|
|
|
it->opacity = qMin(1.0f, oldOpacity + time / m_fadeDuration);
|
2009-02-03 10:51:36 +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
|
|
|
if (it->opacity < 0.98f)
|
2009-02-03 10:51:36 +00:00
|
|
|
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
|
|
|
if (oldOpacity != it->opacity)
|
2016-09-12 09:13:11 +00:00
|
|
|
effects->addRepaint(w->expandedGeometry());
|
2009-02-03 10:51:36 +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
|
|
|
if (it->opacity > 0.98f || it->opacity < 0.02f) {
|
|
|
|
|
m_animations.remove(w); // We default to 1.0
|
|
|
|
|
it = m_animations.end();
|
2015-01-17 22:48:08 +00:00
|
|
|
}
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2009-02-03 10:51:36 +00:00
|
|
|
|
2009-12-20 12:48:54 +00:00
|
|
|
// Show tabbed windows and windows on other desktops if highlighted
|
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 (it != m_animations.end() && it->opacity > 0.01) {
|
2011-12-13 13:28:20 +00:00
|
|
|
if (w->isMinimized())
|
|
|
|
|
w->enablePainting(EffectWindow::PAINT_DISABLED_BY_MINIMIZE);
|
2011-01-30 14:34:42 +00:00
|
|
|
if (!w->isOnCurrentDesktop())
|
|
|
|
|
w->enablePainting(EffectWindow::PAINT_DISABLED_BY_DESKTOP);
|
2009-01-31 15:12:14 +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
|
|
|
effects->prePaintWindow(w, data, presentTime);
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void HighlightWindowEffect::paintWindow(EffectWindow* w, int mask, QRegion region, WindowPaintData& data)
|
|
|
|
|
{
|
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
|
|
|
auto it = m_animations.constFind(w);
|
|
|
|
|
if (it != m_animations.constEnd()) {
|
|
|
|
|
data.multiplyOpacity(it->opacity);
|
|
|
|
|
}
|
2011-01-30 14:34:42 +00:00
|
|
|
effects->paintWindow(w, mask, region, data);
|
|
|
|
|
}
|
2009-01-31 15:12:14 +00:00
|
|
|
|
2011-02-25 21:06:02 +00:00
|
|
|
void HighlightWindowEffect::slotWindowAdded(EffectWindow* w)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
|
|
|
|
if (!m_highlightedWindows.isEmpty()) {
|
|
|
|
|
// The effect is activated thus we need to add it to the opacity hash
|
2013-09-03 19:55:39 +00:00
|
|
|
foreach (const WId id, m_highlightedIds) {
|
|
|
|
|
if (w == effects->findWindow(id)) {
|
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_animations[w].opacity = 1.0; // this window was demanded to be highlighted before it appeared
|
2013-09-03 19:55:39 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
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_animations[w].opacity = 0.15; // this window is not currently highlighted
|
2009-01-31 15:12:14 +00:00
|
|
|
}
|
2013-09-03 19:55:39 +00:00
|
|
|
slotPropertyNotify(w, m_atom, w); // Check initial value
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2009-01-31 15:12:14 +00:00
|
|
|
|
2011-02-27 08:25:45 +00:00
|
|
|
void HighlightWindowEffect::slotWindowClosed(EffectWindow* w)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
|
|
|
|
if (m_monitorWindow == w) // The monitoring window was destroyed
|
2009-02-03 10:51:36 +00:00
|
|
|
finishHighlighting();
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2009-01-31 15:12:14 +00:00
|
|
|
|
2011-02-27 09:47:42 +00:00
|
|
|
void HighlightWindowEffect::slotWindowDeleted(EffectWindow* w)
|
2011-01-30 14:34:42 +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
|
|
|
m_animations.remove(w);
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2009-02-09 12:37:59 +00:00
|
|
|
|
2013-09-03 19:55:39 +00:00
|
|
|
void HighlightWindowEffect::slotPropertyNotify(EffectWindow* w, long a, EffectWindow *addedWindow)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2017-09-10 14:51:18 +00:00
|
|
|
if (a != m_atom || m_atom == XCB_ATOM_NONE)
|
2009-01-31 15:12:14 +00:00
|
|
|
return; // Not our atom
|
|
|
|
|
|
2010-10-17 19:49:07 +00:00
|
|
|
// if the window is null, the property was set on the root window - see events.cpp
|
2011-01-30 14:34:42 +00:00
|
|
|
QByteArray byteData = w ? w->readProperty(m_atom, m_atom, 32) :
|
|
|
|
|
effects->readRootProperty(m_atom, m_atom, 32);
|
|
|
|
|
if (byteData.length() < 1) {
|
|
|
|
|
// Property was removed, clearing highlight
|
2013-09-03 19:55:39 +00:00
|
|
|
if (!addedWindow || w != addedWindow)
|
|
|
|
|
finishHighlighting();
|
2009-02-09 12:37:59 +00:00
|
|
|
return;
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2013-09-25 06:54:22 +00:00
|
|
|
auto* data = reinterpret_cast<uint32_t*>(byteData.data());
|
2009-01-31 15:12:14 +00:00
|
|
|
|
2011-01-30 14:34:42 +00:00
|
|
|
if (!data[0]) {
|
|
|
|
|
// Purposely clearing highlight by issuing a NULL target
|
2009-02-03 10:51:36 +00:00
|
|
|
finishHighlighting();
|
2009-01-31 15:12:14 +00:00
|
|
|
return;
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2009-01-31 15:12:14 +00:00
|
|
|
m_monitorWindow = w;
|
2009-05-05 11:46:36 +00:00
|
|
|
bool found = false;
|
2011-01-30 14:34:42 +00:00
|
|
|
int length = byteData.length() / sizeof(data[0]);
|
|
|
|
|
//foreach ( EffectWindow* e, m_highlightedWindows )
|
2009-12-20 13:21:00 +00:00
|
|
|
// effects->setElevatedWindow( e, false );
|
2009-09-13 11:36:45 +00:00
|
|
|
m_highlightedWindows.clear();
|
2013-09-03 19:55:39 +00:00
|
|
|
m_highlightedIds.clear();
|
2011-01-30 14:34:42 +00:00
|
|
|
for (int i = 0; i < length; i++) {
|
2013-09-03 19:55:39 +00:00
|
|
|
m_highlightedIds << data[i];
|
2011-01-30 14:34:42 +00:00
|
|
|
EffectWindow* foundWin = effects->findWindow(data[i]);
|
|
|
|
|
if (!foundWin) {
|
2013-11-29 05:18:28 +00:00
|
|
|
qCDebug(KWINEFFECTS) << "Invalid window targetted for highlight. Requested:" << data[i];
|
2013-09-03 19:55:39 +00:00
|
|
|
continue; // might come in later.
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2011-12-13 13:28:20 +00:00
|
|
|
m_highlightedWindows.append(foundWin);
|
|
|
|
|
// TODO: We cannot just simply elevate the window as this will elevate it over
|
|
|
|
|
// Plasma tooltips and other such windows as well
|
|
|
|
|
//effects->setElevatedWindow( foundWin, true );
|
2011-01-30 14:34:42 +00:00
|
|
|
found = true;
|
|
|
|
|
}
|
|
|
|
|
if (!found) {
|
2009-09-13 11:36:45 +00:00
|
|
|
finishHighlighting();
|
2009-05-05 11:46:36 +00:00
|
|
|
return;
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2009-02-03 10:51:36 +00:00
|
|
|
prepareHighlighting();
|
2011-01-30 14:34:42 +00:00
|
|
|
if (w)
|
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_animations[w].opacity = 1.0; // Because it's not in stackingOrder() yet
|
2009-02-07 15:40:31 +00:00
|
|
|
|
|
|
|
|
/* TODO: Finish thumbnails of offscreen windows, not sure if it's worth it though
|
2011-01-30 14:34:42 +00:00
|
|
|
if ( !m_highlightedWindow->isOnCurrentDesktop() )
|
2009-02-07 15:40:31 +00:00
|
|
|
{ // Window is offscreen, determine thumbnail position
|
|
|
|
|
QRect screenArea = effects->clientArea( MaximizeArea ); // Workable area of the active screen
|
|
|
|
|
QRect outerArea = outerArea.adjusted( outerArea.width() / 10, outerArea.height() / 10,
|
|
|
|
|
-outerArea.width() / 10, -outerArea.height() / 10 ); // Add 10% margin around the edge
|
|
|
|
|
QRect innerArea = outerArea.adjusted( outerArea.width() / 40, outerArea.height() / 40,
|
|
|
|
|
-outerArea.width() / 40, -outerArea.height() / 40 ); // Outer edge of the thumbnail border (2.5%)
|
|
|
|
|
QRect thumbArea = outerArea.adjusted( 20, 20, -20, -20 ); // Outer edge of the thumbnail (20px)
|
|
|
|
|
|
|
|
|
|
// Determine the maximum size that we can make the thumbnail within the innerArea
|
|
|
|
|
double areaAspect = double( thumbArea.width() ) / double( thumbArea.height() );
|
|
|
|
|
double windowAspect = aspectRatio( m_highlightedWindow );
|
|
|
|
|
QRect thumbRect; // Position doesn't matter right now, but it will later
|
2011-01-30 14:34:42 +00:00
|
|
|
if ( windowAspect > areaAspect )
|
2009-02-07 15:40:31 +00:00
|
|
|
// Top/bottom will touch first
|
|
|
|
|
thumbRect = QRect( 0, 0, widthForHeight( thumbArea.height() ), thumbArea.height() );
|
|
|
|
|
else // Left/right will touch first
|
|
|
|
|
thumbRect = QRect( 0, 0, thumbArea.width(), heightForWidth( thumbArea.width() ));
|
2011-01-30 14:34:42 +00:00
|
|
|
if ( thumbRect.width() >= m_highlightedWindow->width() )
|
2009-02-07 15:40:31 +00:00
|
|
|
// Area is larger than the window, just use the window's size
|
|
|
|
|
thumbRect = m_highlightedWindow->geometry();
|
|
|
|
|
|
|
|
|
|
// Determine position of desktop relative to the current one
|
2009-02-14 14:49:46 +00:00
|
|
|
QPoint direction = effects->desktopGridCoords( m_highlightedWindow->desktop() ) -
|
|
|
|
|
effects->desktopGridCoords( effects->currentDesktop() );
|
2009-02-07 15:40:31 +00:00
|
|
|
|
|
|
|
|
// Draw a line from the center of the current desktop to the center of the target desktop.
|
|
|
|
|
QPointF desktopLine( 0, 0, direction.x() * screenArea.width(), direction.y() * screenArea.height() );
|
|
|
|
|
desktopLeft.translate( screenArea.width() / 2, screenArea.height() / 2 ); // Move to the screen center
|
|
|
|
|
|
|
|
|
|
// Take the point where the line crosses the outerArea, this will be the tip of our arrow
|
|
|
|
|
QPointF arrowTip;
|
|
|
|
|
QLineF testLine( // Top
|
|
|
|
|
outerArea.x(), outerArea.y(),
|
|
|
|
|
outerArea.x() + outerArea.width(), outerArea.y() );
|
2011-01-30 14:34:42 +00:00
|
|
|
if ( desktopLine.intersect( testLine, &arrowTip ) != QLineF::BoundedIntersection )
|
2009-02-07 15:40:31 +00:00
|
|
|
{
|
|
|
|
|
testLine = QLineF( // Right
|
|
|
|
|
outerArea.x() + outerArea.width(), outerArea.y(),
|
|
|
|
|
outerArea.x() + outerArea.width(), outerArea.y() + outerArea.height() );
|
2011-01-30 14:34:42 +00:00
|
|
|
if ( desktopLine.intersect( testLine, &arrowTip ) != QLineF::BoundedIntersection )
|
2009-02-07 15:40:31 +00:00
|
|
|
{
|
|
|
|
|
testLine = QLineF( // Bottom
|
|
|
|
|
outerArea.x() + outerArea.width(), outerArea.y() + outerArea.height(),
|
|
|
|
|
outerArea.x(), outerArea.y() + outerArea.height() );
|
2011-01-30 14:34:42 +00:00
|
|
|
if ( desktopLine.intersect( testLine, &arrowTip ) != QLineF::BoundedIntersection )
|
2009-02-07 15:40:31 +00:00
|
|
|
{
|
|
|
|
|
testLine = QLineF( // Left
|
|
|
|
|
outerArea.x(), outerArea.y() + outerArea.height(),
|
|
|
|
|
outerArea.x(), outerArea.y() );
|
|
|
|
|
desktopLine.intersect( testLine, &arrowTip ); // Should never fail
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
m_arrowTip = arrowTip.toPoint();
|
|
|
|
|
} */
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2009-02-03 10:51:36 +00:00
|
|
|
|
|
|
|
|
void HighlightWindowEffect::prepareHighlighting()
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2009-02-03 10:51:36 +00:00
|
|
|
// Create window data for every window. Just calling [w] creates it.
|
|
|
|
|
m_finishing = false;
|
2011-12-13 13:28:20 +00:00
|
|
|
foreach (EffectWindow * w, effects->stackingOrder()) {
|
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 (!m_animations.contains(w)) // Just in case we are still finishing from last time
|
|
|
|
|
m_animations[w].opacity = isInitiallyHidden(w) ? 0.0 : 1.0;
|
2011-12-13 13:28:20 +00:00
|
|
|
if (!m_highlightedWindows.isEmpty())
|
|
|
|
|
m_highlightedWindows.at(0)->addRepaintFull();
|
|
|
|
|
}
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2009-02-03 10:51:36 +00:00
|
|
|
|
|
|
|
|
void HighlightWindowEffect::finishHighlighting()
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2009-02-03 10:51:36 +00:00
|
|
|
m_finishing = true;
|
Use nullptr everywhere
Summary:
Because KWin is a very old project, we use three kinds of null pointer
literals: 0, NULL, and nullptr. Since C++11, it's recommended to use
nullptr keyword.
This change converts all usages of 0 and NULL literal to nullptr. Even
though it breaks git history, we need to do it in order to have consistent
code as well to ease code reviews (it's very tempting for some people to
add unrelated changes to their patches, e.g. converting NULL to nullptr).
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, davidedmundson, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23618
2019-09-19 14:46:54 +00:00
|
|
|
m_monitorWindow = nullptr;
|
2009-05-05 11:46:36 +00:00
|
|
|
m_highlightedWindows.clear();
|
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 (!m_animations.isEmpty())
|
|
|
|
|
m_animations.constBegin().key()->addRepaintFull();
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2009-01-31 15:12:14 +00:00
|
|
|
|
2016-08-30 13:50:31 +00:00
|
|
|
void HighlightWindowEffect::highlightWindows(const QVector<KWin::EffectWindow *> &windows)
|
|
|
|
|
{
|
|
|
|
|
if (windows.isEmpty()) {
|
|
|
|
|
finishHighlighting();
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
m_monitorWindow = nullptr;
|
|
|
|
|
m_highlightedWindows.clear();
|
|
|
|
|
m_highlightedIds.clear();
|
|
|
|
|
for (auto w : windows) {
|
|
|
|
|
m_highlightedWindows << w;
|
|
|
|
|
}
|
|
|
|
|
prepareHighlighting();
|
|
|
|
|
}
|
|
|
|
|
|
2011-08-27 09:21:31 +00:00
|
|
|
bool HighlightWindowEffect::isActive() const
|
|
|
|
|
{
|
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
|
|
|
return !(m_animations.isEmpty() || effects->isScreenLocked());
|
2011-08-27 09:21:31 +00:00
|
|
|
}
|
|
|
|
|
|
2016-08-30 13:50:31 +00:00
|
|
|
bool HighlightWindowEffect::provides(Feature feature)
|
|
|
|
|
{
|
|
|
|
|
switch (feature) {
|
|
|
|
|
case HighlightWindows:
|
|
|
|
|
return true;
|
|
|
|
|
default:
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool HighlightWindowEffect::perform(Feature feature, const QVariantList &arguments)
|
|
|
|
|
{
|
|
|
|
|
if (feature != HighlightWindows) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
if (arguments.size() != 1) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
highlightWindows(arguments.first().value<QVector<EffectWindow*>>());
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2009-01-31 15:12:14 +00:00
|
|
|
} // namespace
|
