2020-08-02 22:22:19 +00:00
|
|
|
/*
|
|
|
|
|
KWin - the KDE window manager
|
|
|
|
|
This file is part of the KDE project.
|
2008-08-02 13:17:21 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-FileCopyrightText: 2008 Martin Gräßlin <mgraesslin@kde.org>
|
2008-08-02 13:17:21 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
|
*/
|
2008-08-02 13:17:21 +00:00
|
|
|
|
|
|
|
|
// based on minimize animation by Rivo Laks <rivolaks@hot.ee>
|
|
|
|
|
|
|
|
|
|
#include "magiclamp.h"
|
2012-09-19 07:29:27 +00:00
|
|
|
// KConfigSkeleton
|
|
|
|
|
#include "magiclampconfig.h"
|
|
|
|
|
|
2008-08-02 13:17:21 +00:00
|
|
|
namespace KWin
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
MagicLampEffect::MagicLampEffect()
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2016-12-02 19:27:43 +00:00
|
|
|
initConfig<MagicLampConfig>();
|
2011-01-30 14:34:42 +00:00
|
|
|
reconfigure(ReconfigureAll);
|
2019-01-01 20:48:53 +00:00
|
|
|
connect(effects, &EffectsHandler::windowDeleted, this, &MagicLampEffect::slotWindowDeleted);
|
|
|
|
|
connect(effects, &EffectsHandler::windowMinimized, this, &MagicLampEffect::slotWindowMinimized);
|
|
|
|
|
connect(effects, &EffectsHandler::windowUnminimized, this, &MagicLampEffect::slotWindowUnminimized);
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2008-08-02 13:17:21 +00:00
|
|
|
|
2009-04-01 09:56:01 +00:00
|
|
|
bool MagicLampEffect::supported()
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2016-08-10 07:24:53 +00:00
|
|
|
return effects->isOpenGLCompositing() && effects->animationsSupported();
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2009-04-01 09:56:01 +00:00
|
|
|
|
2011-01-30 14:34:42 +00:00
|
|
|
void MagicLampEffect::reconfigure(ReconfigureFlags)
|
|
|
|
|
{
|
2014-03-25 15:29:03 +00:00
|
|
|
MagicLampConfig::self()->read();
|
2018-06-27 14:52:09 +00:00
|
|
|
|
|
|
|
|
// TODO: Rename animationDuration to duration so we can use
|
|
|
|
|
// animationTime<MagicLampConfig>(250).
|
|
|
|
|
const int d = MagicLampConfig::animationDuration() != 0
|
|
|
|
|
? MagicLampConfig::animationDuration()
|
|
|
|
|
: 250;
|
|
|
|
|
m_duration = std::chrono::milliseconds(static_cast<int>(animationTime(d)));
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2008-08-02 13:17:21 +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 MagicLampEffect::prePaintScreen(ScreenPrePaintData& data, std::chrono::milliseconds presentTime)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2018-06-27 14:52:09 +00:00
|
|
|
auto animationIt = m_animations.begin();
|
|
|
|
|
while (animationIt != m_animations.end()) {
|
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 (animationIt->lastPresentTime.count()) {
|
|
|
|
|
delta = presentTime - animationIt->lastPresentTime;
|
|
|
|
|
}
|
|
|
|
|
animationIt->lastPresentTime = presentTime;
|
|
|
|
|
|
|
|
|
|
(*animationIt).timeLine.update(delta);
|
2018-06-27 14:52:09 +00:00
|
|
|
++animationIt;
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
|
|
|
|
|
2018-06-27 14:52:09 +00:00
|
|
|
// We need to mark the screen windows as transformed. Otherwise the
|
|
|
|
|
// whole screen won't be repainted, resulting in artefacts.
|
|
|
|
|
data.mask |= PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS;
|
2008-08-02 13:17:21 +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->prePaintScreen(data, presentTime);
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2008-08-02 13:17:21 +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 MagicLampEffect::prePaintWindow(EffectWindow* w, WindowPrePaintData& data, std::chrono::milliseconds presentTime)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2009-11-25 17:46:50 +00:00
|
|
|
// Schedule window for transformation if the animation is still in
|
|
|
|
|
// progress
|
2018-06-27 14:52:09 +00:00
|
|
|
if (m_animations.contains(w)) {
|
2009-11-25 17:46:50 +00:00
|
|
|
// We'll transform this window
|
|
|
|
|
data.setTransformed();
|
2011-01-30 14:34:42 +00:00
|
|
|
data.quads = data.quads.makeGrid(40);
|
|
|
|
|
w->enablePainting(EffectWindow::PAINT_DISABLED_BY_MINIMIZE);
|
2008-08-02 13:17:21 +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 MagicLampEffect::paintWindow(EffectWindow* w, int mask, QRegion region, WindowPaintData& data)
|
|
|
|
|
{
|
2018-06-27 14:52:09 +00:00
|
|
|
auto animationIt = m_animations.constFind(w);
|
|
|
|
|
if (animationIt != m_animations.constEnd()) {
|
2008-08-02 13:17:21 +00:00
|
|
|
// 0 = not minimized, 1 = fully minimized
|
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
|
|
|
const qreal progress = (*animationIt).timeLine.value();
|
2008-08-02 13:17:21 +00:00
|
|
|
|
|
|
|
|
QRect geo = w->geometry();
|
|
|
|
|
QRect icon = w->iconGeometry();
|
2009-11-25 17:46:50 +00:00
|
|
|
IconPosition position = Top;
|
2008-08-02 13:17:21 +00:00
|
|
|
// If there's no icon geometry, minimize to the center of the screen
|
2011-01-30 14:34:42 +00:00
|
|
|
if (!icon.isValid()) {
|
2016-11-11 10:14:30 +00:00
|
|
|
QRect extG = geo;
|
2013-02-26 07:45:44 +00:00
|
|
|
QPoint pt = cursorPos();
|
2009-11-25 17:46:50 +00:00
|
|
|
// focussing inside the window is no good, leads to ugly artefacts, find nearest border
|
2011-01-30 14:34:42 +00:00
|
|
|
if (extG.contains(pt)) {
|
2009-11-25 17:46:50 +00:00
|
|
|
const int d[2][2] = { {pt.x() - extG.x(), extG.right() - pt.x()},
|
2011-01-30 14:34:42 +00:00
|
|
|
{pt.y() - extG.y(), extG.bottom() - pt.y()}
|
|
|
|
|
};
|
2009-11-25 17:46:50 +00:00
|
|
|
int di = d[1][0];
|
|
|
|
|
position = Top;
|
2011-01-30 14:34:42 +00:00
|
|
|
if (d[0][0] < di) {
|
2009-11-25 17:46:50 +00:00
|
|
|
di = d[0][0];
|
|
|
|
|
position = Left;
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
|
|
|
|
if (d[1][1] < di) {
|
2009-11-25 17:46:50 +00:00
|
|
|
di = d[1][1];
|
2009-03-08 15:12:55 +00:00
|
|
|
position = Bottom;
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2009-11-25 17:46:50 +00:00
|
|
|
if (d[0][1] < di)
|
|
|
|
|
position = Right;
|
2011-01-30 14:34:42 +00:00
|
|
|
switch(position) {
|
|
|
|
|
case Top: pt.setY(extG.y()); break;
|
|
|
|
|
case Left: pt.setX(extG.x()); break;
|
|
|
|
|
case Bottom: pt.setY(extG.bottom()); break;
|
|
|
|
|
case Right: pt.setX(extG.right()); break;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
2009-11-25 17:46:50 +00:00
|
|
|
if (pt.y() < geo.y())
|
|
|
|
|
position = Top;
|
|
|
|
|
else if (pt.x() < geo.x())
|
2009-03-08 15:12:55 +00:00
|
|
|
position = Left;
|
2009-11-25 17:46:50 +00:00
|
|
|
else if (pt.y() > geo.bottom())
|
|
|
|
|
position = Bottom;
|
|
|
|
|
else if (pt.x() > geo.right())
|
2009-03-08 15:12:55 +00:00
|
|
|
position = Right;
|
2008-08-22 09:40:46 +00:00
|
|
|
}
|
2011-01-30 14:34:42 +00:00
|
|
|
icon = QRect(pt, QSize(0, 0));
|
|
|
|
|
} else {
|
2009-11-25 17:46:50 +00:00
|
|
|
// Assumption: there is a panel containing the icon position
|
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
|
|
|
EffectWindow* panel = nullptr;
|
2011-01-30 14:34:42 +00:00
|
|
|
foreach (EffectWindow * window, effects->stackingOrder()) {
|
|
|
|
|
if (!window->isDock())
|
2009-11-25 17:46:50 +00:00
|
|
|
continue;
|
|
|
|
|
// we have to use intersects as there seems to be a Plasma bug
|
|
|
|
|
// the published icon geometry might be bigger than the panel
|
2011-01-30 14:34:42 +00:00
|
|
|
if (window->geometry().intersects(icon)) {
|
2009-11-25 17:46:50 +00:00
|
|
|
panel = window;
|
|
|
|
|
break;
|
2009-03-08 15:12:55 +00:00
|
|
|
}
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
|
|
|
|
if (panel) {
|
2009-11-25 17:46:50 +00:00
|
|
|
// Assumption: width of horizonal panel is greater than its height and vice versa
|
|
|
|
|
// The panel has to border one screen edge, so get it's screen area
|
2011-01-30 14:34:42 +00:00
|
|
|
QRect panelScreen = effects->clientArea(ScreenArea, panel);
|
|
|
|
|
if (panel->width() >= panel->height()) {
|
2009-11-25 17:46:50 +00:00
|
|
|
// horizontal panel
|
2020-11-18 01:34:57 +00:00
|
|
|
if (panel->y() <= panelScreen.height()/2)
|
2009-11-25 17:46:50 +00:00
|
|
|
position = Top;
|
|
|
|
|
else
|
|
|
|
|
position = Bottom;
|
2011-01-30 14:34:42 +00:00
|
|
|
} else {
|
2009-11-25 17:46:50 +00:00
|
|
|
// vertical panel
|
2020-11-18 01:34:57 +00:00
|
|
|
if (panel->x() <= panelScreen.width()/2)
|
2009-11-25 17:46:50 +00:00
|
|
|
position = Left;
|
|
|
|
|
else
|
|
|
|
|
position = Right;
|
2009-03-08 15:12:55 +00:00
|
|
|
}
|
2011-01-30 14:34:42 +00:00
|
|
|
} else {
|
2009-11-25 17:46:50 +00:00
|
|
|
// we did not find a panel, so it might be autohidden
|
2011-01-30 14:34:42 +00:00
|
|
|
QRect iconScreen = effects->clientArea(ScreenArea, icon.topLeft(), effects->currentDesktop());
|
2009-11-25 17:46:50 +00:00
|
|
|
// as the icon geometry could be overlap a screen edge we use an intersection
|
2011-01-30 14:34:42 +00:00
|
|
|
QRect rect = iconScreen.intersected(icon);
|
2009-11-25 17:46:50 +00:00
|
|
|
// here we need a different assumption: icon geometry borders one screen edge
|
|
|
|
|
// this assumption might be wrong for e.g. task applet being the only applet in panel
|
|
|
|
|
// in this case the icon borders two screen edges
|
|
|
|
|
// there might be a wrong animation, but not distorted
|
2011-01-30 14:34:42 +00:00
|
|
|
if (rect.x() == iconScreen.x()) {
|
2009-11-25 17:46:50 +00:00
|
|
|
position = Left;
|
2011-01-30 14:34:42 +00:00
|
|
|
} else if (rect.x() + rect.width() == iconScreen.x() + iconScreen.width()) {
|
2009-11-25 17:46:50 +00:00
|
|
|
position = Right;
|
2011-01-30 14:34:42 +00:00
|
|
|
} else if (rect.y() == iconScreen.y()) {
|
2009-11-25 17:46:50 +00:00
|
|
|
position = Top;
|
2011-01-30 14:34:42 +00:00
|
|
|
} else {
|
2009-11-25 17:46:50 +00:00
|
|
|
position = Bottom;
|
2009-03-08 15:12:55 +00:00
|
|
|
}
|
2008-08-22 09:40:46 +00:00
|
|
|
}
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2008-08-02 13:17:21 +00:00
|
|
|
|
2011-12-01 00:58:43 +00:00
|
|
|
#define SANITIZE_PROGRESS if (p_progress[0] < 0)\
|
|
|
|
|
p_progress[0] = -p_progress[0];\
|
|
|
|
|
if (p_progress[1] < 0)\
|
|
|
|
|
p_progress[1] = -p_progress[1]
|
|
|
|
|
#define SET_QUADS(_SET_A_, _A_, _DA_, _SET_B_, _B_, _O0_, _O1_, _O2_, _O3_) quad[0]._SET_A_((icon._A_() + icon._DA_()*(quad[0]._A_() / geo._DA_()) - (quad[0]._A_() + geo._A_()))*p_progress[_O0_] + quad[0]._A_());\
|
|
|
|
|
quad[1]._SET_A_((icon._A_() + icon._DA_()*(quad[1]._A_() / geo._DA_()) - (quad[1]._A_() + geo._A_()))*p_progress[_O1_] + quad[1]._A_());\
|
|
|
|
|
quad[2]._SET_A_((icon._A_() + icon._DA_()*(quad[2]._A_() / geo._DA_()) - (quad[2]._A_() + geo._A_()))*p_progress[_O2_] + quad[2]._A_());\
|
|
|
|
|
quad[3]._SET_A_((icon._A_() + icon._DA_()*(quad[3]._A_() / geo._DA_()) - (quad[3]._A_() + geo._A_()))*p_progress[_O3_] + quad[3]._A_());\
|
|
|
|
|
\
|
|
|
|
|
quad[0]._SET_B_(quad[0]._B_() + offset[_O0_]);\
|
|
|
|
|
quad[1]._SET_B_(quad[1]._B_() + offset[_O1_]);\
|
|
|
|
|
quad[2]._SET_B_(quad[2]._B_() + offset[_O2_]);\
|
|
|
|
|
quad[3]._SET_B_(quad[3]._B_() + offset[_O3_])
|
|
|
|
|
|
2008-08-02 13:17:21 +00:00
|
|
|
WindowQuadList newQuads;
|
2018-07-14 19:48:45 +00:00
|
|
|
newQuads.reserve(data.quads.count());
|
2011-12-01 00:58:43 +00:00
|
|
|
float quadFactor; // defines how fast a quad is vertically moved: y coordinates near to window top are slowed down
|
|
|
|
|
// it is used as quadFactor^3/windowHeight^3
|
|
|
|
|
// quadFactor is the y position of the quad but is changed towards becomming the window height
|
|
|
|
|
// by that the factor becomes 1 and has no influence any more
|
|
|
|
|
float offset[2] = {0,0}; // how far has a quad to be moved? Distance between icon and window multiplied by the progress and by the quadFactor
|
|
|
|
|
float p_progress[2] = {0,0}; // the factor which defines how far the x values have to be changed
|
|
|
|
|
// factor is the current moved y value diveded by the distance between icon and window
|
|
|
|
|
WindowQuad lastQuad(WindowQuadError);
|
|
|
|
|
lastQuad[0].setX(-1);
|
|
|
|
|
lastQuad[0].setY(-1);
|
|
|
|
|
lastQuad[1].setX(-1);
|
|
|
|
|
lastQuad[1].setY(-1);
|
|
|
|
|
lastQuad[2].setX(-1);
|
|
|
|
|
lastQuad[2].setY(-1);
|
|
|
|
|
|
|
|
|
|
if (position == Bottom) {
|
|
|
|
|
float height_cube = float(geo.height()) * float(geo.height()) * float(geo.height());
|
|
|
|
|
foreach (WindowQuad quad, data.quads) { // krazy:exclude=foreach
|
|
|
|
|
|
|
|
|
|
if (quad[0].y() != lastQuad[0].y() || quad[2].y() != lastQuad[2].y()) {
|
2011-01-30 14:34:42 +00:00
|
|
|
quadFactor = quad[0].y() + (geo.height() - quad[0].y()) * progress;
|
2011-12-01 00:58:43 +00:00
|
|
|
offset[0] = (icon.y() + quad[0].y() - geo.y()) * progress * ((quadFactor * quadFactor * quadFactor) / height_cube);
|
2011-01-30 14:34:42 +00:00
|
|
|
quadFactor = quad[2].y() + (geo.height() - quad[2].y()) * progress;
|
2011-12-01 00:58:43 +00:00
|
|
|
offset[1] = (icon.y() + quad[2].y() - geo.y()) * progress * ((quadFactor * quadFactor * quadFactor) / height_cube);
|
|
|
|
|
p_progress[1] = qMin(offset[1] / (icon.y() + icon.height() - geo.y() - float(quad[2].y())), 1.0f);
|
|
|
|
|
p_progress[0] = qMin(offset[0] / (icon.y() + icon.height() - geo.y() - float(quad[0].y())), 1.0f);
|
|
|
|
|
} else
|
|
|
|
|
lastQuad = quad;
|
|
|
|
|
|
|
|
|
|
SANITIZE_PROGRESS;
|
|
|
|
|
// x values are moved towards the center of the icon
|
|
|
|
|
SET_QUADS(setX, x, width, setY, y, 0,0,1,1);
|
|
|
|
|
|
|
|
|
|
newQuads.append(quad);
|
|
|
|
|
}
|
|
|
|
|
} else if (position == Top) {
|
|
|
|
|
float height_cube = float(geo.height()) * float(geo.height()) * float(geo.height());
|
|
|
|
|
foreach (WindowQuad quad, data.quads) { // krazy:exclude=foreach
|
|
|
|
|
|
|
|
|
|
if (quad[0].y() != lastQuad[0].y() || quad[2].y() != lastQuad[2].y()) {
|
2011-01-30 14:34:42 +00:00
|
|
|
quadFactor = geo.height() - quad[0].y() + (quad[0].y()) * progress;
|
2011-12-01 00:58:43 +00:00
|
|
|
offset[0] = (geo.y() - icon.height() + geo.height() + quad[0].y() - icon.y()) * progress * ((quadFactor * quadFactor * quadFactor) / height_cube);
|
2011-01-30 14:34:42 +00:00
|
|
|
quadFactor = geo.height() - quad[2].y() + (quad[2].y()) * progress;
|
2011-12-01 00:58:43 +00:00
|
|
|
offset[1] = (geo.y() - icon.height() + geo.height() + quad[2].y() - icon.y()) * progress * ((quadFactor * quadFactor * quadFactor) / height_cube);
|
|
|
|
|
p_progress[0] = qMin(offset[0] / (geo.y() - icon.height() + geo.height() - icon.y() - float(geo.height() - quad[0].y())), 1.0f);
|
|
|
|
|
p_progress[1] = qMin(offset[1] / (geo.y() - icon.height() + geo.height() - icon.y() - float(geo.height() - quad[2].y())), 1.0f);
|
|
|
|
|
} else
|
|
|
|
|
lastQuad = quad;
|
|
|
|
|
|
|
|
|
|
offset[0] = -offset[0];
|
|
|
|
|
offset[1] = -offset[1];
|
2008-08-22 09:40:46 +00:00
|
|
|
|
2011-12-01 00:58:43 +00:00
|
|
|
SANITIZE_PROGRESS;
|
2008-08-22 09:40:46 +00:00
|
|
|
// x values are moved towards the center of the icon
|
2011-12-01 00:58:43 +00:00
|
|
|
SET_QUADS(setX, x, width, setY, y, 0,0,1,1);
|
|
|
|
|
|
|
|
|
|
newQuads.append(quad);
|
|
|
|
|
}
|
|
|
|
|
} else if (position == Left) {
|
|
|
|
|
float width_cube = float(geo.width()) * float(geo.width()) * float(geo.width());
|
|
|
|
|
foreach (WindowQuad quad, data.quads) { // krazy:exclude=foreach
|
|
|
|
|
|
|
|
|
|
if (quad[0].x() != lastQuad[0].x() || quad[1].x() != lastQuad[1].x()) {
|
2011-01-30 14:34:42 +00:00
|
|
|
quadFactor = geo.width() - quad[0].x() + (quad[0].x()) * progress;
|
2011-12-01 00:58:43 +00:00
|
|
|
offset[0] = (geo.x() - icon.width() + geo.width() + quad[0].x() - icon.x()) * progress * ((quadFactor * quadFactor * quadFactor) / width_cube);
|
2011-01-30 14:34:42 +00:00
|
|
|
quadFactor = geo.width() - quad[1].x() + (quad[1].x()) * progress;
|
2011-12-01 00:58:43 +00:00
|
|
|
offset[1] = (geo.x() - icon.width() + geo.width() + quad[1].x() - icon.x()) * progress * ((quadFactor * quadFactor * quadFactor) / width_cube);
|
|
|
|
|
p_progress[0] = qMin(offset[0] / (geo.x() - icon.width() + geo.width() - icon.x() - float(geo.width() - quad[0].x())), 1.0f);
|
|
|
|
|
p_progress[1] = qMin(offset[1] / (geo.x() - icon.width() + geo.width() - icon.x() - float(geo.width() - quad[1].x())), 1.0f);
|
|
|
|
|
} else
|
|
|
|
|
lastQuad = quad;
|
|
|
|
|
|
|
|
|
|
offset[0] = -offset[0];
|
|
|
|
|
offset[1] = -offset[1];
|
|
|
|
|
|
|
|
|
|
SANITIZE_PROGRESS;
|
|
|
|
|
// y values are moved towards the center of the icon
|
|
|
|
|
SET_QUADS(setY, y, height, setX, x, 0,1,1,0);
|
|
|
|
|
|
|
|
|
|
newQuads.append(quad);
|
|
|
|
|
}
|
|
|
|
|
} else if (position == Right) {
|
|
|
|
|
float width_cube = float(geo.width()) * float(geo.width()) * float(geo.width());
|
|
|
|
|
foreach (WindowQuad quad, data.quads) { // krazy:exclude=foreach
|
|
|
|
|
|
|
|
|
|
if (quad[0].x() != lastQuad[0].x() || quad[1].x() != lastQuad[1].x()) {
|
|
|
|
|
quadFactor = quad[0].x() + (geo.width() - quad[0].x()) * progress;
|
|
|
|
|
offset[0] = (icon.x() + quad[0].x() - geo.x()) * progress * ((quadFactor * quadFactor * quadFactor) / width_cube);
|
|
|
|
|
quadFactor = quad[1].x() + (geo.width() - quad[1].x()) * progress;
|
|
|
|
|
offset[1] = (icon.x() + quad[1].x() - geo.x()) * progress * ((quadFactor * quadFactor * quadFactor) / width_cube);
|
|
|
|
|
p_progress[0] = qMin(offset[0] / (icon.x() + icon.width() - geo.x() - float(quad[0].x())), 1.0f);
|
|
|
|
|
p_progress[1] = qMin(offset[1] / (icon.x() + icon.width() - geo.x() - float(quad[1].x())), 1.0f);
|
|
|
|
|
} else
|
|
|
|
|
lastQuad = quad;
|
|
|
|
|
|
|
|
|
|
SANITIZE_PROGRESS;
|
|
|
|
|
// y values are moved towards the center of the icon
|
|
|
|
|
SET_QUADS(setY, y, height, setX, x, 0,1,1,0);
|
|
|
|
|
|
|
|
|
|
newQuads.append(quad);
|
2008-08-02 13:17:21 +00:00
|
|
|
}
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2008-08-02 13:17:21 +00:00
|
|
|
data.quads = newQuads;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Call the next effect.
|
2011-01-30 14:34:42 +00:00
|
|
|
effects->paintWindow(w, mask, region, data);
|
|
|
|
|
}
|
2008-08-02 13:17:21 +00:00
|
|
|
|
|
|
|
|
void MagicLampEffect::postPaintScreen()
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2018-06-27 14:52:09 +00:00
|
|
|
auto animationIt = m_animations.begin();
|
|
|
|
|
while (animationIt != m_animations.end()) {
|
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 ((*animationIt).timeLine.done()) {
|
2018-06-27 14:52:09 +00:00
|
|
|
animationIt = m_animations.erase(animationIt);
|
|
|
|
|
} else {
|
|
|
|
|
++animationIt;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
effects->addRepaintFull();
|
2008-08-02 13:17:21 +00:00
|
|
|
|
|
|
|
|
// Call the next effect.
|
|
|
|
|
effects->postPaintScreen();
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2008-08-02 13:17:21 +00:00
|
|
|
|
2011-02-27 09:47:42 +00:00
|
|
|
void MagicLampEffect::slotWindowDeleted(EffectWindow* w)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2018-06-27 14:52:09 +00:00
|
|
|
m_animations.remove(w);
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2009-11-25 16:36:44 +00:00
|
|
|
|
2011-03-06 09:55:27 +00:00
|
|
|
void MagicLampEffect::slotWindowMinimized(EffectWindow* w)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
|
|
|
|
if (effects->activeFullScreenEffect())
|
2011-01-01 18:56:12 +00:00
|
|
|
return;
|
2018-06-27 14:52:09 +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
|
|
|
MagicLampAnimation &animation = m_animations[w];
|
2018-06-27 14:52:09 +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 (animation.timeLine.running()) {
|
|
|
|
|
animation.timeLine.toggleDirection();
|
2018-06-27 14:52:09 +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
|
|
|
animation.timeLine.setDirection(TimeLine::Forward);
|
|
|
|
|
animation.timeLine.setDuration(m_duration);
|
|
|
|
|
animation.timeLine.setEasingCurve(QEasingCurve::Linear);
|
2011-03-14 21:50:05 +00:00
|
|
|
}
|
2018-06-27 14:52:09 +00:00
|
|
|
|
|
|
|
|
effects->addRepaintFull();
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2008-08-02 13:17:21 +00:00
|
|
|
|
2011-03-06 10:08:19 +00:00
|
|
|
void MagicLampEffect::slotWindowUnminimized(EffectWindow* w)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
|
|
|
|
if (effects->activeFullScreenEffect())
|
2011-01-01 18:56:12 +00:00
|
|
|
return;
|
2018-06-27 14:52:09 +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
|
|
|
MagicLampAnimation &animation = m_animations[w];
|
2018-06-27 14:52:09 +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 (animation.timeLine.running()) {
|
|
|
|
|
animation.timeLine.toggleDirection();
|
2018-06-27 14:52:09 +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
|
|
|
animation.timeLine.setDirection(TimeLine::Backward);
|
|
|
|
|
animation.timeLine.setDuration(m_duration);
|
|
|
|
|
animation.timeLine.setEasingCurve(QEasingCurve::Linear);
|
2011-03-14 21:50:05 +00:00
|
|
|
}
|
2018-06-27 14:52:09 +00:00
|
|
|
|
|
|
|
|
effects->addRepaintFull();
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2008-08-02 13:17:21 +00:00
|
|
|
|
2011-08-27 09:21:31 +00:00
|
|
|
bool MagicLampEffect::isActive() const
|
|
|
|
|
{
|
2018-06-27 14:52:09 +00:00
|
|
|
return !m_animations.isEmpty();
|
2011-08-27 09:21:31 +00:00
|
|
|
}
|
|
|
|
|
|
2008-08-02 13:17:21 +00:00
|
|
|
} // namespace
|
