2020-08-02 22:22:19 +00:00
|
|
|
/*
|
|
|
|
KWin - the KDE window manager
|
|
|
|
This file is part of the KDE project.
|
2007-04-29 17:35:43 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-FileCopyrightText: 2006 Lubos Lunak <l.lunak@kde.org>
|
2007-04-29 17:35:43 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
*/
|
2012-08-30 06:20:26 +00:00
|
|
|
#include "composite.h"
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
#include "abstract_output.h"
|
2014-06-02 06:51:28 +00:00
|
|
|
#include "dbusinterface.h"
|
2019-09-24 08:48:08 +00:00
|
|
|
#include "x11client.h"
|
2019-06-22 10:00:56 +00:00
|
|
|
#include "decorations/decoratedclient.h"
|
2007-04-29 17:35:43 +00:00
|
|
|
#include "deleted.h"
|
|
|
|
#include "effects.h"
|
2020-09-07 08:11:47 +00:00
|
|
|
#include "ftrace.h"
|
2019-08-26 07:44:04 +00:00
|
|
|
#include "internal_client.h"
|
2011-07-06 09:58:23 +00:00
|
|
|
#include "overlaywindow.h"
|
2019-06-22 10:00:56 +00:00
|
|
|
#include "platform.h"
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
#include "renderloop.h"
|
2007-04-29 17:35:43 +00:00
|
|
|
#include "scene.h"
|
2014-11-25 07:40:23 +00:00
|
|
|
#include "screens.h"
|
2011-03-27 10:33:07 +00:00
|
|
|
#include "shadow.h"
|
2021-02-04 09:07:20 +00:00
|
|
|
#include "surfaceitem_x11.h"
|
2019-06-22 10:00:56 +00:00
|
|
|
#include "unmanaged.h"
|
|
|
|
#include "useractions.h"
|
|
|
|
#include "utils.h"
|
2015-03-23 13:29:07 +00:00
|
|
|
#include "wayland_server.h"
|
2019-06-22 10:00:56 +00:00
|
|
|
#include "workspace.h"
|
|
|
|
#include "xcbutils.h"
|
2007-04-29 17:35:43 +00:00
|
|
|
|
2017-09-08 20:30:18 +00:00
|
|
|
#include <kwingltexture.h>
|
|
|
|
|
2020-04-29 15:18:41 +00:00
|
|
|
#include <KWaylandServer/surface_interface.h>
|
2015-02-24 10:50:01 +00:00
|
|
|
|
2014-03-17 15:24:10 +00:00
|
|
|
#include <KGlobalAccel>
|
|
|
|
#include <KLocalizedString>
|
2017-08-10 16:13:42 +00:00
|
|
|
#include <KPluginLoader>
|
|
|
|
#include <KPluginMetaData>
|
2014-03-17 15:24:10 +00:00
|
|
|
#include <KNotification>
|
2019-06-22 10:40:12 +00:00
|
|
|
#include <KSelectionOwner>
|
2007-04-29 17:35:43 +00:00
|
|
|
|
2019-06-22 10:00:56 +00:00
|
|
|
#include <QDateTime>
|
|
|
|
#include <QFutureWatcher>
|
|
|
|
#include <QMenu>
|
|
|
|
#include <QOpenGLContext>
|
|
|
|
#include <QQuickWindow>
|
|
|
|
#include <QtConcurrentRun>
|
|
|
|
#include <QTextStream>
|
|
|
|
#include <QTimerEvent>
|
|
|
|
|
2012-12-11 20:21:35 +00:00
|
|
|
#include <xcb/composite.h>
|
2012-03-28 18:29:33 +00:00
|
|
|
#include <xcb/damage.h>
|
|
|
|
|
2019-06-22 10:00:56 +00:00
|
|
|
#include <cstdio>
|
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
Q_DECLARE_METATYPE(KWin::X11Compositor::SuspendReason)
|
2013-01-09 15:03:54 +00:00
|
|
|
|
2007-04-29 17:35:43 +00:00
|
|
|
namespace KWin
|
|
|
|
{
|
|
|
|
|
2019-08-08 12:34:22 +00:00
|
|
|
// See main.cpp:
|
|
|
|
extern int screen_number;
|
|
|
|
|
2019-07-04 01:19:18 +00:00
|
|
|
extern bool is_multihead;
|
2010-11-27 15:27:54 +00:00
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
Compositor *Compositor::s_compositor = nullptr;
|
|
|
|
Compositor *Compositor::self()
|
|
|
|
{
|
|
|
|
return s_compositor;
|
|
|
|
}
|
|
|
|
|
|
|
|
WaylandCompositor *WaylandCompositor::create(QObject *parent)
|
|
|
|
{
|
|
|
|
Q_ASSERT(!s_compositor);
|
|
|
|
auto *compositor = new WaylandCompositor(parent);
|
|
|
|
s_compositor = compositor;
|
|
|
|
return compositor;
|
|
|
|
}
|
|
|
|
X11Compositor *X11Compositor::create(QObject *parent)
|
|
|
|
{
|
|
|
|
Q_ASSERT(!s_compositor);
|
|
|
|
auto *compositor = new X11Compositor(parent);
|
|
|
|
s_compositor = compositor;
|
|
|
|
return compositor;
|
|
|
|
}
|
|
|
|
|
2019-06-22 10:40:12 +00:00
|
|
|
class CompositorSelectionOwner : public KSelectionOwner
|
2013-04-26 15:11:37 +00:00
|
|
|
{
|
2019-06-22 10:40:12 +00:00
|
|
|
Q_OBJECT
|
|
|
|
public:
|
|
|
|
CompositorSelectionOwner(const char *selection)
|
|
|
|
: KSelectionOwner(selection, connection(), rootWindow())
|
|
|
|
, m_owning(false)
|
|
|
|
{
|
|
|
|
connect (this, &CompositorSelectionOwner::lostOwnership,
|
|
|
|
this, [this]() { m_owning = false; });
|
|
|
|
}
|
|
|
|
bool owning() const {
|
|
|
|
return m_owning;
|
|
|
|
}
|
|
|
|
void setOwning(bool own) {
|
|
|
|
m_owning = own;
|
|
|
|
}
|
|
|
|
private:
|
|
|
|
bool m_owning;
|
|
|
|
};
|
2013-04-26 15:11:37 +00:00
|
|
|
|
2012-08-16 15:10:47 +00:00
|
|
|
Compositor::Compositor(QObject* workspace)
|
2011-08-21 19:50:23 +00:00
|
|
|
: QObject(workspace)
|
2019-07-04 01:19:18 +00:00
|
|
|
, m_state(State::Off)
|
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_selectionOwner(nullptr)
|
2019-12-24 23:54:40 +00:00
|
|
|
, m_scene(nullptr)
|
2011-08-21 19:50:23 +00:00
|
|
|
{
|
2019-08-07 17:33:20 +00:00
|
|
|
connect(options, &Options::configChanged, this, &Compositor::configChanged);
|
2019-09-25 13:31:48 +00:00
|
|
|
connect(options, &Options::animationSpeedChanged, this, &Compositor::configChanged);
|
2019-07-02 22:57:53 +00:00
|
|
|
|
2019-08-08 12:34:22 +00:00
|
|
|
// 2 sec which should be enough to restart the compositor.
|
2013-04-26 22:00:23 +00:00
|
|
|
static const int compositorLostMessageDelay = 2000;
|
|
|
|
|
|
|
|
m_releaseSelectionTimer.setSingleShot(true);
|
|
|
|
m_releaseSelectionTimer.setInterval(compositorLostMessageDelay);
|
2019-08-08 12:34:22 +00:00
|
|
|
connect(&m_releaseSelectionTimer, &QTimer::timeout,
|
|
|
|
this, &Compositor::releaseCompositorSelection);
|
2013-04-26 22:00:23 +00:00
|
|
|
|
|
|
|
m_unusedSupportPropertyTimer.setInterval(compositorLostMessageDelay);
|
|
|
|
m_unusedSupportPropertyTimer.setSingleShot(true);
|
2019-08-08 12:34:22 +00:00
|
|
|
connect(&m_unusedSupportPropertyTimer, &QTimer::timeout,
|
|
|
|
this, &Compositor::deleteUnusedSupportProperties);
|
2016-04-15 09:19:12 +00:00
|
|
|
|
2019-07-04 01:19:18 +00:00
|
|
|
// Delay the call to start by one event cycle.
|
2016-04-15 09:19:12 +00:00
|
|
|
// The ctor of this class is invoked from the Workspace ctor, that means before
|
|
|
|
// Workspace is completely constructed, so calling Workspace::self() would result
|
|
|
|
// in undefined behavior. This is fixed by using a delayed invocation.
|
|
|
|
if (kwinApp()->platform()->isReady()) {
|
2019-08-07 17:33:20 +00:00
|
|
|
QTimer::singleShot(0, this, &Compositor::start);
|
2014-08-13 10:54:02 +00:00
|
|
|
}
|
2016-04-15 09:19:12 +00:00
|
|
|
connect(kwinApp()->platform(), &Platform::readyChanged, this,
|
|
|
|
[this] (bool ready) {
|
|
|
|
if (ready) {
|
2019-07-04 01:19:18 +00:00
|
|
|
start();
|
2016-04-15 09:19:12 +00:00
|
|
|
} else {
|
2019-07-04 01:19:18 +00:00
|
|
|
stop();
|
2016-04-15 09:19:12 +00:00
|
|
|
}
|
|
|
|
}, Qt::QueuedConnection
|
|
|
|
);
|
2014-06-02 06:51:28 +00:00
|
|
|
|
|
|
|
// register DBus
|
|
|
|
new CompositorDBusInterface(this);
|
2020-09-07 08:11:47 +00:00
|
|
|
FTraceLogger::create();
|
2011-08-21 19:50:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
Compositor::~Compositor()
|
|
|
|
{
|
2021-06-08 07:02:14 +00:00
|
|
|
Q_EMIT aboutToDestroy();
|
2019-07-04 01:19:18 +00:00
|
|
|
stop();
|
2013-04-26 22:00:23 +00:00
|
|
|
deleteUnusedSupportProperties();
|
2019-08-07 17:33:20 +00:00
|
|
|
destroyCompositorSelection();
|
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
|
|
|
s_compositor = nullptr;
|
2011-08-21 19:50:23 +00:00
|
|
|
}
|
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
bool Compositor::setupStart()
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2019-01-06 16:05:10 +00:00
|
|
|
if (kwinApp()->isTerminating()) {
|
2019-08-08 12:34:22 +00:00
|
|
|
// Don't start while KWin is terminating. An event to restart might be lingering
|
|
|
|
// in the event queue due to graphics reset.
|
2019-08-07 17:33:20 +00:00
|
|
|
return false;
|
2019-01-06 16:05:10 +00:00
|
|
|
}
|
2019-07-04 01:19:18 +00:00
|
|
|
if (m_state != State::Off) {
|
2019-08-07 17:33:20 +00:00
|
|
|
return false;
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2019-07-04 01:19:18 +00:00
|
|
|
m_state = State::Starting;
|
2011-02-27 22:39:32 +00:00
|
|
|
|
2019-07-02 19:09:23 +00:00
|
|
|
options->reloadCompositingSettings(true);
|
2007-07-19 16:20:05 +00:00
|
|
|
|
2020-07-20 08:07:08 +00:00
|
|
|
initializeX11();
|
2014-04-14 07:19:43 +00:00
|
|
|
|
2019-08-08 12:34:22 +00:00
|
|
|
// There might still be a deleted around, needs to be cleared before
|
|
|
|
// creating the scene (BUG 333275).
|
2015-02-23 14:57:00 +00:00
|
|
|
if (Workspace::self()) {
|
|
|
|
while (!Workspace::self()->deletedList().isEmpty()) {
|
|
|
|
Workspace::self()->deletedList().first()->discard();
|
|
|
|
}
|
2014-04-14 07:19:43 +00:00
|
|
|
}
|
|
|
|
|
2021-06-08 07:02:14 +00:00
|
|
|
Q_EMIT aboutToToggleCompositing();
|
2019-02-20 13:09:37 +00:00
|
|
|
|
2017-10-18 19:56:13 +00:00
|
|
|
auto supportedCompositors = kwinApp()->platform()->supportedCompositors();
|
2019-08-08 12:34:22 +00:00
|
|
|
const auto userConfigIt = std::find(supportedCompositors.begin(), supportedCompositors.end(),
|
|
|
|
options->compositingMode());
|
|
|
|
|
2017-10-18 19:56:13 +00:00
|
|
|
if (userConfigIt != supportedCompositors.end()) {
|
|
|
|
supportedCompositors.erase(userConfigIt);
|
|
|
|
supportedCompositors.prepend(options->compositingMode());
|
|
|
|
} else {
|
2019-08-08 12:34:22 +00:00
|
|
|
qCWarning(KWIN_CORE)
|
|
|
|
<< "Configured compositor not supported by Platform. Falling back to defaults";
|
2017-10-18 19:56:13 +00:00
|
|
|
}
|
|
|
|
|
2017-08-10 16:13:42 +00:00
|
|
|
const auto availablePlugins = KPluginLoader::findPlugins(QStringLiteral("org.kde.kwin.scenes"));
|
2011-01-30 14:34:42 +00:00
|
|
|
|
2020-04-28 17:19:08 +00:00
|
|
|
for (const KPluginMetaData &pluginMetaData : availablePlugins) {
|
|
|
|
qCDebug(KWIN_CORE) << "Available scene plugin:" << pluginMetaData.fileName();
|
|
|
|
}
|
|
|
|
|
2017-10-18 19:56:13 +00:00
|
|
|
for (auto type : qAsConst(supportedCompositors)) {
|
2020-04-28 17:19:08 +00:00
|
|
|
switch (type) {
|
|
|
|
case OpenGLCompositing:
|
|
|
|
case OpenGL2Compositing:
|
|
|
|
qCDebug(KWIN_CORE) << "Attempting to load the OpenGL scene";
|
|
|
|
break;
|
|
|
|
case QPainterCompositing:
|
|
|
|
qCDebug(KWIN_CORE) << "Attempting to load the QPainter scene";
|
|
|
|
break;
|
|
|
|
case NoCompositing:
|
|
|
|
Q_UNREACHABLE();
|
|
|
|
}
|
2017-10-18 19:56:13 +00:00
|
|
|
const auto pluginIt = std::find_if(availablePlugins.begin(), availablePlugins.end(),
|
|
|
|
[type] (const auto &plugin) {
|
|
|
|
const auto &metaData = plugin.rawData();
|
|
|
|
auto it = metaData.find(QStringLiteral("CompositingType"));
|
|
|
|
if (it != metaData.end()) {
|
|
|
|
if ((*it).toInt() == int{type}) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
});
|
|
|
|
if (pluginIt != availablePlugins.end()) {
|
2019-08-08 12:34:22 +00:00
|
|
|
std::unique_ptr<SceneFactory>
|
|
|
|
factory{ qobject_cast<SceneFactory*>(pluginIt->instantiate()) };
|
2017-10-18 19:56:13 +00:00
|
|
|
if (factory) {
|
|
|
|
m_scene = factory->create(this);
|
|
|
|
if (m_scene) {
|
|
|
|
if (!m_scene->initFailed()) {
|
2019-08-08 12:34:22 +00:00
|
|
|
qCDebug(KWIN_CORE) << "Instantiated compositing plugin:"
|
|
|
|
<< pluginIt->name();
|
2017-10-18 19:56:13 +00:00
|
|
|
break;
|
|
|
|
} else {
|
|
|
|
delete m_scene;
|
|
|
|
m_scene = nullptr;
|
|
|
|
}
|
2017-08-10 16:13:42 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
if (m_scene == nullptr || m_scene->initFailed()) {
|
2014-12-05 10:42:15 +00:00
|
|
|
qCCritical(KWIN_CORE) << "Failed to initialize compositing, compositing disabled";
|
2019-07-04 01:19:18 +00:00
|
|
|
m_state = State::Off;
|
|
|
|
|
2012-08-16 19:19:54 +00:00
|
|
|
delete m_scene;
|
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_scene = nullptr;
|
2019-07-04 01:19:18 +00:00
|
|
|
|
2019-06-22 10:40:12 +00:00
|
|
|
if (m_selectionOwner) {
|
|
|
|
m_selectionOwner->setOwning(false);
|
|
|
|
m_selectionOwner->release();
|
2015-02-23 14:57:00 +00:00
|
|
|
}
|
2017-10-18 19:56:13 +00:00
|
|
|
if (!supportedCompositors.contains(NoCompositing)) {
|
2014-12-05 10:42:15 +00:00
|
|
|
qCCritical(KWIN_CORE) << "The used windowing system requires compositing";
|
|
|
|
qCCritical(KWIN_CORE) << "We are going to quit KWin now as it is broken";
|
2013-06-25 08:39:13 +00:00
|
|
|
qApp->quit();
|
|
|
|
}
|
2019-08-07 17:33:20 +00:00
|
|
|
return false;
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2017-11-05 10:07:04 +00:00
|
|
|
|
2019-08-08 12:34:22 +00:00
|
|
|
CompositingType compositingType = m_scene->compositingType();
|
|
|
|
if (compositingType & OpenGLCompositing) {
|
|
|
|
// Override for OpenGl sub-type OpenGL2Compositing.
|
|
|
|
compositingType = OpenGLCompositing;
|
|
|
|
}
|
|
|
|
kwinApp()->platform()->setSelectedCompositor(compositingType);
|
2019-02-16 19:50:46 +00:00
|
|
|
|
2017-11-05 10:07:04 +00:00
|
|
|
if (!Workspace::self() && m_scene && m_scene->compositingType() == QPainterCompositing) {
|
2019-08-08 12:34:22 +00:00
|
|
|
// Force Software QtQuick on first startup with QPainter.
|
2017-11-05 10:07:04 +00:00
|
|
|
QQuickWindow::setSceneGraphBackend(QSGRendererInterface::Software);
|
|
|
|
}
|
|
|
|
|
2019-07-02 20:30:27 +00:00
|
|
|
connect(m_scene, &Scene::resetCompositing, this, &Compositor::reinitialize);
|
2021-06-08 07:02:14 +00:00
|
|
|
Q_EMIT sceneCreated();
|
2015-02-23 14:57:00 +00:00
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
return true;
|
2015-02-23 14:57:00 +00:00
|
|
|
}
|
|
|
|
|
2020-07-20 08:07:08 +00:00
|
|
|
void Compositor::initializeX11()
|
2015-02-23 14:57:00 +00:00
|
|
|
{
|
2020-07-20 08:07:08 +00:00
|
|
|
xcb_connection_t *connection = kwinApp()->x11Connection();
|
|
|
|
if (!connection) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-06-22 10:40:12 +00:00
|
|
|
if (!m_selectionOwner) {
|
2015-02-23 14:57:00 +00:00
|
|
|
char selection_name[ 100 ];
|
|
|
|
sprintf(selection_name, "_NET_WM_CM_S%d", Application::x11ScreenNumber());
|
2019-06-22 10:40:12 +00:00
|
|
|
m_selectionOwner = new CompositorSelectionOwner(selection_name);
|
2019-08-08 12:34:22 +00:00
|
|
|
connect(m_selectionOwner, &CompositorSelectionOwner::lostOwnership,
|
|
|
|
this, &Compositor::stop);
|
2015-02-23 14:57:00 +00:00
|
|
|
}
|
2019-06-22 10:40:12 +00:00
|
|
|
if (!m_selectionOwner->owning()) {
|
2019-08-08 12:34:22 +00:00
|
|
|
// Force claim ownership.
|
|
|
|
m_selectionOwner->claim(true);
|
2019-06-22 10:40:12 +00:00
|
|
|
m_selectionOwner->setOwning(true);
|
2015-02-23 14:57:00 +00:00
|
|
|
}
|
2020-07-20 08:07:08 +00:00
|
|
|
|
|
|
|
xcb_composite_redirect_subwindows(connection, kwinApp()->x11RootWindow(),
|
|
|
|
XCB_COMPOSITE_REDIRECT_MANUAL);
|
2015-02-23 14:57:00 +00:00
|
|
|
}
|
|
|
|
|
2020-07-20 08:07:08 +00:00
|
|
|
void Compositor::cleanupX11()
|
2017-08-24 08:43:38 +00:00
|
|
|
{
|
2020-07-20 08:07:08 +00:00
|
|
|
delete m_selectionOwner;
|
|
|
|
m_selectionOwner = nullptr;
|
2017-08-24 08:43:38 +00:00
|
|
|
}
|
|
|
|
|
2015-02-23 14:57:00 +00:00
|
|
|
void Compositor::startupWithWorkspace()
|
|
|
|
{
|
2019-08-08 12:34:22 +00:00
|
|
|
connect(kwinApp(), &Application::x11ConnectionChanged,
|
2020-07-20 08:07:08 +00:00
|
|
|
this, &Compositor::initializeX11, Qt::UniqueConnection);
|
|
|
|
connect(kwinApp(), &Application::x11ConnectionAboutToBeDestroyed,
|
|
|
|
this, &Compositor::cleanupX11, Qt::UniqueConnection);
|
|
|
|
initializeX11();
|
|
|
|
|
2017-06-21 19:10:12 +00:00
|
|
|
Workspace::self()->markXStackingOrderAsDirty();
|
2015-02-23 14:57:00 +00:00
|
|
|
Q_ASSERT(m_scene);
|
2019-08-08 12:34:22 +00:00
|
|
|
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
const Platform *platform = kwinApp()->platform();
|
|
|
|
if (platform->isPerScreenRenderingEnabled()) {
|
|
|
|
const QVector<AbstractOutput *> outputs = platform->enabledOutputs();
|
|
|
|
for (AbstractOutput *output : outputs) {
|
|
|
|
registerRenderLoop(output->renderLoop(), output);
|
|
|
|
}
|
|
|
|
connect(platform, &Platform::outputEnabled,
|
|
|
|
this, &Compositor::handleOutputEnabled);
|
|
|
|
connect(platform, &Platform::outputDisabled,
|
|
|
|
this, &Compositor::handleOutputDisabled);
|
2020-01-09 17:18:22 +00:00
|
|
|
} else {
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
registerRenderLoop(platform->renderLoop(), nullptr);
|
2020-01-09 17:18:22 +00:00
|
|
|
}
|
2019-08-08 12:34:22 +00:00
|
|
|
|
|
|
|
// Sets also the 'effects' pointer.
|
|
|
|
kwinApp()->platform()->createEffectsHandler(this, m_scene);
|
2019-01-11 18:55:17 +00:00
|
|
|
connect(Workspace::self(), &Workspace::deletedRemoved, m_scene, &Scene::removeToplevel);
|
2019-07-02 18:28:45 +00:00
|
|
|
connect(effects, &EffectsHandler::screenGeometryChanged, this, &Compositor::addRepaintFull);
|
2019-08-08 12:34:22 +00:00
|
|
|
|
2019-09-24 08:48:08 +00:00
|
|
|
for (X11Client *c : Workspace::self()->clientList()) {
|
2012-03-29 20:11:28 +00:00
|
|
|
c->setupCompositing();
|
2019-09-29 11:26:04 +00:00
|
|
|
c->updateShadow();
|
2012-12-27 20:57:40 +00:00
|
|
|
}
|
2019-08-08 12:34:22 +00:00
|
|
|
for (Unmanaged *c : Workspace::self()->unmanagedList()) {
|
2012-03-29 20:11:28 +00:00
|
|
|
c->setupCompositing();
|
2019-09-29 11:26:04 +00:00
|
|
|
c->updateShadow();
|
2012-12-27 20:57:40 +00:00
|
|
|
}
|
2019-08-26 07:44:04 +00:00
|
|
|
for (InternalClient *client : workspace()->internalClients()) {
|
|
|
|
client->setupCompositing();
|
2019-09-29 11:26:04 +00:00
|
|
|
client->updateShadow();
|
2019-08-26 07:44:04 +00:00
|
|
|
}
|
2019-08-08 12:34:22 +00:00
|
|
|
|
|
|
|
if (auto *server = waylandServer()) {
|
|
|
|
const auto clients = server->clients();
|
2020-03-04 07:55:26 +00:00
|
|
|
for (AbstractClient *c : clients) {
|
2016-07-15 14:06:09 +00:00
|
|
|
c->setupCompositing();
|
2019-09-29 11:26:04 +00:00
|
|
|
c->updateShadow();
|
2016-07-15 14:06:09 +00:00
|
|
|
}
|
|
|
|
}
|
2012-04-13 09:36:48 +00:00
|
|
|
|
2019-07-04 01:19:18 +00:00
|
|
|
m_state = State::On;
|
2021-06-08 07:02:14 +00:00
|
|
|
Q_EMIT compositingToggled(true);
|
2012-09-01 07:10:56 +00:00
|
|
|
|
2012-10-14 10:18:35 +00:00
|
|
|
if (m_releaseSelectionTimer.isActive()) {
|
|
|
|
m_releaseSelectionTimer.stop();
|
|
|
|
}
|
|
|
|
|
2019-08-08 12:34:22 +00:00
|
|
|
// Render at least once.
|
2019-09-05 07:39:20 +00:00
|
|
|
addRepaintFull();
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void Compositor::registerRenderLoop(RenderLoop *renderLoop, AbstractOutput *output)
|
|
|
|
{
|
|
|
|
Q_ASSERT(!m_renderLoops.contains(renderLoop));
|
|
|
|
m_renderLoops.insert(renderLoop, output);
|
|
|
|
connect(renderLoop, &RenderLoop::frameRequested, this, &Compositor::handleFrameRequested);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Compositor::unregisterRenderLoop(RenderLoop *renderLoop)
|
|
|
|
{
|
|
|
|
Q_ASSERT(m_renderLoops.contains(renderLoop));
|
|
|
|
m_renderLoops.remove(renderLoop);
|
|
|
|
disconnect(renderLoop, &RenderLoop::frameRequested, this, &Compositor::handleFrameRequested);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Compositor::handleOutputEnabled(AbstractOutput *output)
|
|
|
|
{
|
|
|
|
registerRenderLoop(output->renderLoop(), output);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Compositor::handleOutputDisabled(AbstractOutput *output)
|
|
|
|
{
|
|
|
|
unregisterRenderLoop(output->renderLoop());
|
|
|
|
}
|
|
|
|
|
|
|
|
int Compositor::screenForRenderLoop(RenderLoop *renderLoop) const
|
|
|
|
{
|
|
|
|
Q_ASSERT(m_renderLoops.contains(renderLoop));
|
|
|
|
AbstractOutput *output = m_renderLoops.value(renderLoop);
|
|
|
|
if (!output) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return kwinApp()->platform()->enabledOutputs().indexOf(output);
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2007-04-29 17:35:43 +00:00
|
|
|
|
2012-08-23 11:42:59 +00:00
|
|
|
void Compositor::scheduleRepaint()
|
2011-08-21 19:50:23 +00:00
|
|
|
{
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
for (auto it = m_renderLoops.constBegin(); it != m_renderLoops.constEnd(); ++it) {
|
|
|
|
it.key()->scheduleRepaint();
|
|
|
|
}
|
2011-08-21 19:50:23 +00:00
|
|
|
}
|
|
|
|
|
2019-07-04 01:19:18 +00:00
|
|
|
void Compositor::stop()
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2019-07-04 01:19:18 +00:00
|
|
|
if (m_state == State::Off || m_state == State::Stopping) {
|
2007-04-29 17:35:43 +00:00
|
|
|
return;
|
2019-07-04 01:19:18 +00:00
|
|
|
}
|
|
|
|
m_state = State::Stopping;
|
2021-06-08 07:02:14 +00:00
|
|
|
Q_EMIT aboutToToggleCompositing();
|
2019-02-20 13:09:37 +00:00
|
|
|
|
2019-07-04 01:19:18 +00:00
|
|
|
m_releaseSelectionTimer.start();
|
|
|
|
|
2018-12-01 16:23:37 +00:00
|
|
|
// Some effects might need access to effect windows when they are about to
|
|
|
|
// be destroyed, for example to unreference deleted windows, so we have to
|
|
|
|
// make sure that effect windows outlive effects.
|
|
|
|
delete effects;
|
|
|
|
effects = nullptr;
|
|
|
|
|
2015-05-27 07:12:07 +00:00
|
|
|
if (Workspace::self()) {
|
2019-09-24 08:48:08 +00:00
|
|
|
for (X11Client *c : Workspace::self()->clientList()) {
|
2019-01-11 18:55:17 +00:00
|
|
|
m_scene->removeToplevel(c);
|
2019-08-08 12:34:22 +00:00
|
|
|
}
|
|
|
|
for (Unmanaged *c : Workspace::self()->unmanagedList()) {
|
2019-01-11 18:55:17 +00:00
|
|
|
m_scene->removeToplevel(c);
|
2019-08-08 12:34:22 +00:00
|
|
|
}
|
2019-08-26 07:44:04 +00:00
|
|
|
for (InternalClient *client : workspace()->internalClients()) {
|
|
|
|
m_scene->removeToplevel(client);
|
|
|
|
}
|
2019-09-24 08:48:08 +00:00
|
|
|
for (X11Client *c : Workspace::self()->clientList()) {
|
2019-08-08 12:34:22 +00:00
|
|
|
c->finishCompositing();
|
|
|
|
}
|
|
|
|
for (Unmanaged *c : Workspace::self()->unmanagedList()) {
|
|
|
|
c->finishCompositing();
|
|
|
|
}
|
2019-08-26 07:44:04 +00:00
|
|
|
for (InternalClient *client : workspace()->internalClients()) {
|
|
|
|
client->finishCompositing();
|
|
|
|
}
|
2019-12-02 17:36:13 +00:00
|
|
|
if (auto *con = kwinApp()->x11Connection()) {
|
|
|
|
xcb_composite_unredirect_subwindows(con, kwinApp()->x11RootWindow(),
|
|
|
|
XCB_COMPOSITE_REDIRECT_MANUAL);
|
|
|
|
}
|
2019-02-10 21:37:06 +00:00
|
|
|
while (!workspace()->deletedList().isEmpty()) {
|
|
|
|
workspace()->deletedList().first()->discard();
|
|
|
|
}
|
2015-05-27 07:12:07 +00:00
|
|
|
}
|
2019-08-08 12:34:22 +00:00
|
|
|
|
2016-08-18 09:51:54 +00:00
|
|
|
if (waylandServer()) {
|
2020-03-04 07:55:26 +00:00
|
|
|
for (AbstractClient *c : waylandServer()->clients()) {
|
2019-01-11 18:55:17 +00:00
|
|
|
m_scene->removeToplevel(c);
|
2016-08-18 09:51:54 +00:00
|
|
|
}
|
2020-03-04 07:55:26 +00:00
|
|
|
for (AbstractClient *c : waylandServer()->clients()) {
|
2016-08-18 09:51:54 +00:00
|
|
|
c->finishCompositing();
|
|
|
|
}
|
|
|
|
}
|
2019-08-08 12:34:22 +00:00
|
|
|
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
while (!m_renderLoops.isEmpty()) {
|
|
|
|
unregisterRenderLoop(m_renderLoops.firstKey());
|
|
|
|
}
|
|
|
|
|
|
|
|
disconnect(kwinApp()->platform(), &Platform::outputEnabled,
|
|
|
|
this, &Compositor::handleOutputEnabled);
|
|
|
|
disconnect(kwinApp()->platform(), &Platform::outputDisabled,
|
|
|
|
this, &Compositor::handleOutputDisabled);
|
|
|
|
|
2012-08-16 19:19:54 +00:00
|
|
|
delete m_scene;
|
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_scene = nullptr;
|
2019-07-04 01:19:18 +00:00
|
|
|
|
|
|
|
m_state = State::Off;
|
2021-06-08 07:02:14 +00:00
|
|
|
Q_EMIT compositingToggled(false);
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2007-04-29 17:35:43 +00:00
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
void Compositor::destroyCompositorSelection()
|
|
|
|
{
|
|
|
|
delete m_selectionOwner;
|
|
|
|
m_selectionOwner = nullptr;
|
|
|
|
}
|
|
|
|
|
2012-10-14 10:18:35 +00:00
|
|
|
void Compositor::releaseCompositorSelection()
|
|
|
|
{
|
2019-07-04 01:19:18 +00:00
|
|
|
switch (m_state) {
|
|
|
|
case State::On:
|
|
|
|
// We are compositing at the moment. Don't release.
|
|
|
|
break;
|
|
|
|
case State::Off:
|
|
|
|
if (m_selectionOwner) {
|
|
|
|
qCDebug(KWIN_CORE) << "Releasing compositor selection";
|
|
|
|
m_selectionOwner->setOwning(false);
|
|
|
|
m_selectionOwner->release();
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case State::Starting:
|
|
|
|
case State::Stopping:
|
|
|
|
// Still starting or shutting down the compositor. Starting might fail
|
|
|
|
// or after stopping a restart might follow. So test again later on.
|
2012-10-14 10:18:35 +00:00
|
|
|
m_releaseSelectionTimer.start();
|
2019-07-04 01:19:18 +00:00
|
|
|
break;
|
2015-02-23 14:57:00 +00:00
|
|
|
}
|
2012-10-14 10:18:35 +00:00
|
|
|
}
|
|
|
|
|
2013-04-26 22:00:23 +00:00
|
|
|
void Compositor::keepSupportProperty(xcb_atom_t atom)
|
|
|
|
{
|
|
|
|
m_unusedSupportProperties.removeAll(atom);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Compositor::removeSupportProperty(xcb_atom_t atom)
|
|
|
|
{
|
|
|
|
m_unusedSupportProperties << atom;
|
|
|
|
m_unusedSupportPropertyTimer.start();
|
|
|
|
}
|
|
|
|
|
|
|
|
void Compositor::deleteUnusedSupportProperties()
|
|
|
|
{
|
2019-07-04 01:19:18 +00:00
|
|
|
if (m_state == State::Starting || m_state == State::Stopping) {
|
|
|
|
// Currently still maybe restarting the compositor.
|
2013-04-26 22:00:23 +00:00
|
|
|
m_unusedSupportPropertyTimer.start();
|
|
|
|
return;
|
|
|
|
}
|
2019-08-08 12:34:22 +00:00
|
|
|
if (auto *con = kwinApp()->x11Connection()) {
|
|
|
|
for (const xcb_atom_t &atom : qAsConst(m_unusedSupportProperties)) {
|
2015-11-10 12:54:26 +00:00
|
|
|
// remove property from root window
|
2019-08-08 12:34:22 +00:00
|
|
|
xcb_delete_property(con, kwinApp()->x11RootWindow(), atom);
|
2015-11-10 12:54:26 +00:00
|
|
|
}
|
2019-09-05 07:55:31 +00:00
|
|
|
m_unusedSupportProperties.clear();
|
2013-04-26 22:00:23 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
void Compositor::configChanged()
|
2011-08-21 19:50:23 +00:00
|
|
|
{
|
2019-08-07 17:33:20 +00:00
|
|
|
reinitialize();
|
|
|
|
addRepaintFull();
|
2011-08-21 19:50:23 +00:00
|
|
|
}
|
|
|
|
|
2019-07-02 20:30:27 +00:00
|
|
|
void Compositor::reinitialize()
|
2011-08-21 19:50:23 +00:00
|
|
|
{
|
2019-07-04 01:19:18 +00:00
|
|
|
// Reparse config. Config options will be reloaded by start()
|
2016-01-29 10:24:18 +00:00
|
|
|
kwinApp()->config()->reparseConfiguration();
|
2012-08-17 08:15:33 +00:00
|
|
|
|
2011-08-21 19:50:23 +00:00
|
|
|
// Restart compositing
|
2019-07-04 01:19:18 +00:00
|
|
|
stop();
|
|
|
|
start();
|
2012-08-17 08:15:33 +00:00
|
|
|
|
2019-07-04 01:19:18 +00:00
|
|
|
if (effects) { // start() may fail
|
2012-08-17 08:15:33 +00:00
|
|
|
effects->reconfigure();
|
|
|
|
}
|
2011-08-21 19:50:23 +00:00
|
|
|
}
|
|
|
|
|
2020-11-20 09:35:38 +00:00
|
|
|
void Compositor::addRepaint(int x, int y, int width, int height)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2020-11-20 09:35:38 +00:00
|
|
|
addRepaint(QRegion(x, y, width, height));
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2007-04-29 17:35:43 +00:00
|
|
|
|
2020-11-20 09:35:38 +00:00
|
|
|
void Compositor::addRepaint(const QRect &rect)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2020-11-20 09:35:38 +00:00
|
|
|
addRepaint(QRegion(rect));
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
|
|
|
|
2020-11-20 09:35:38 +00:00
|
|
|
void Compositor::addRepaint(const QRegion ®ion)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2020-11-20 09:35:38 +00:00
|
|
|
if (m_scene) {
|
|
|
|
m_scene->addRepaint(region);
|
2019-09-05 16:06:03 +00:00
|
|
|
}
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
|
|
|
|
2011-08-21 19:50:23 +00:00
|
|
|
void Compositor::addRepaintFull()
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2020-11-20 09:35:38 +00:00
|
|
|
addRepaint(screens()->geometry());
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2007-04-29 17:35:43 +00:00
|
|
|
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
void Compositor::handleFrameRequested(RenderLoop *renderLoop)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2021-04-29 06:07:45 +00:00
|
|
|
composite(renderLoop);
|
2021-02-03 14:19:55 +00:00
|
|
|
}
|
2015-08-31 11:54:50 +00:00
|
|
|
|
2021-02-03 14:19:55 +00:00
|
|
|
void Compositor::composite(RenderLoop *renderLoop)
|
|
|
|
{
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
const int screenId = screenForRenderLoop(renderLoop);
|
|
|
|
|
2020-09-07 08:11:47 +00:00
|
|
|
fTraceDuration("Paint (", screens()->name(screenId), ")");
|
|
|
|
|
2012-03-28 18:29:33 +00:00
|
|
|
// Create a list of all windows in the stacking order
|
Drop some custom list typedefs
Summary:
Qt has its own thing where a type might also have corresponding list
alias, e.g. QObject and QObjectList, QWidget and QWidgetList. I don't
know why Qt does that, maybe for some historical reasons, but what
matters is that we copy this pattern here in KWin. While this pattern
might be useful with some long list types, for example
QList<QWeakPointer<TabBoxClient>> TabBoxClientList
in general, it causes more harm than good. For example, we've got two
new client types, do we need corresponding list typedefs for them? If
no, why do we have ClientList and so on?
Another problem with these typedefs is that you need to include utils.h
header in order to use them. A better way to handle such things is to
just forward declare a client class (if that's possible) and use it
directly with QList or QVector. This way translation units don't get
"bloated" with utils.h stuff for no apparent reason.
So, in order to make code more consistent and easier to follow, this
change drops some of our custom typedefs. Namely ConstClientList,
ClientList, DeletedList, UnmanagedList, ToplevelList, and GroupList.
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24950
2019-10-16 09:11:04 +00:00
|
|
|
QList<Toplevel *> windows = Workspace::self()->xStackingOrder();
|
2012-03-28 18:29:33 +00:00
|
|
|
|
|
|
|
// Move elevated windows to the top of the stacking order
|
2019-08-08 12:34:22 +00:00
|
|
|
for (EffectWindow *c : static_cast<EffectsHandlerImpl *>(effects)->elevatedWindows()) {
|
|
|
|
Toplevel *t = static_cast<EffectWindowImpl *>(c)->window();
|
2012-03-28 18:29:33 +00:00
|
|
|
windows.removeAll(t);
|
|
|
|
windows.append(t);
|
|
|
|
}
|
|
|
|
|
2019-08-08 12:34:22 +00:00
|
|
|
// Skip windows that are not yet ready for being painted and if screen is locked skip windows
|
|
|
|
// that are neither lockscreen nor inputmethod windows.
|
|
|
|
//
|
|
|
|
// TODO? This cannot be used so carelessly - needs protections against broken clients, the
|
|
|
|
// window should not get focus before it's displayed, handle unredirected windows properly and
|
|
|
|
// so on.
|
|
|
|
for (Toplevel *win : windows) {
|
|
|
|
if (!win->readyForPainting()) {
|
|
|
|
windows.removeAll(win);
|
2015-11-16 10:46:20 +00:00
|
|
|
}
|
|
|
|
if (waylandServer() && waylandServer()->isScreenLocked()) {
|
2019-08-08 12:34:22 +00:00
|
|
|
if(!win->isLockScreen() && !win->isInputMethod()) {
|
|
|
|
windows.removeAll(win);
|
2015-11-16 10:46:20 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2011-08-13 14:39:58 +00:00
|
|
|
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
const QRegion repaints = m_scene->repaints(screenId);
|
|
|
|
m_scene->resetRepaints(screenId);
|
|
|
|
|
2021-01-26 12:18:29 +00:00
|
|
|
m_scene->paint(screenId, repaints, windows, renderLoop);
|
2020-11-20 09:35:38 +00:00
|
|
|
|
2016-05-12 10:17:27 +00:00
|
|
|
if (waylandServer()) {
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
const std::chrono::milliseconds frameTime =
|
|
|
|
std::chrono::duration_cast<std::chrono::milliseconds>(renderLoop->lastPresentationTimestamp());
|
|
|
|
|
|
|
|
for (Toplevel *window : qAsConst(windows)) {
|
|
|
|
if (!window->readyForPainting()) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (waylandServer()->isScreenLocked() &&
|
|
|
|
!(window->isLockScreen() || window->isInputMethod())) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!window->isOnScreen(screenId)) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (auto surface = window->surface()) {
|
|
|
|
surface->frameRendered(frameTime.count());
|
2015-02-24 10:50:01 +00:00
|
|
|
}
|
|
|
|
}
|
2020-10-26 08:02:17 +00:00
|
|
|
if (!kwinApp()->platform()->isCursorHidden()) {
|
|
|
|
Cursors::self()->currentCursor()->markAsRendered();
|
|
|
|
}
|
2015-02-24 10:50:01 +00:00
|
|
|
}
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2008-08-30 15:28:47 +00:00
|
|
|
|
2012-08-17 06:18:36 +00:00
|
|
|
bool Compositor::isActive()
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2019-07-04 01:19:18 +00:00
|
|
|
return m_state == State::On;
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2008-08-15 11:09:07 +00:00
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
WaylandCompositor::WaylandCompositor(QObject *parent)
|
|
|
|
: Compositor(parent)
|
|
|
|
{
|
|
|
|
connect(kwinApp(), &Application::x11ConnectionAboutToBeDestroyed,
|
|
|
|
this, &WaylandCompositor::destroyCompositorSelection);
|
|
|
|
}
|
|
|
|
|
|
|
|
void WaylandCompositor::toggleCompositing()
|
|
|
|
{
|
2019-08-08 12:34:22 +00:00
|
|
|
// For the shortcut. Not possible on Wayland because we always composite.
|
2019-08-07 17:33:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void WaylandCompositor::start()
|
|
|
|
{
|
|
|
|
if (!Compositor::setupStart()) {
|
|
|
|
// Internal setup failed, abort.
|
|
|
|
return;
|
|
|
|
}
|
2019-08-08 12:34:22 +00:00
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
if (Workspace::self()) {
|
|
|
|
startupWithWorkspace();
|
|
|
|
} else {
|
2019-08-08 12:34:22 +00:00
|
|
|
connect(kwinApp(), &Application::workspaceCreated,
|
|
|
|
this, &WaylandCompositor::startupWithWorkspace);
|
2019-08-07 17:33:20 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
X11Compositor::X11Compositor(QObject *parent)
|
|
|
|
: Compositor(parent)
|
|
|
|
, m_suspended(options->isUseCompositing() ? NoReasonSuspend : UserSuspend)
|
|
|
|
{
|
2021-04-04 11:45:44 +00:00
|
|
|
if (qEnvironmentVariableIsSet("KWIN_MAX_FRAMES_TESTED")) {
|
|
|
|
m_framesToTestForSafety = qEnvironmentVariableIntValue("KWIN_MAX_FRAMES_TESTED");
|
|
|
|
}
|
2019-08-07 17:33:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void X11Compositor::toggleCompositing()
|
|
|
|
{
|
2019-08-08 12:34:22 +00:00
|
|
|
if (m_suspended) {
|
|
|
|
// Direct user call; clear all bits.
|
2019-08-07 17:33:20 +00:00
|
|
|
resume(AllReasonSuspend);
|
2019-08-08 12:34:22 +00:00
|
|
|
} else {
|
|
|
|
// But only set the user one (sufficient to suspend).
|
2019-08-07 17:33:20 +00:00
|
|
|
suspend(UserSuspend);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void X11Compositor::reinitialize()
|
|
|
|
{
|
2019-08-08 12:34:22 +00:00
|
|
|
// Resume compositing if suspended.
|
2019-08-07 17:33:20 +00:00
|
|
|
m_suspended = NoReasonSuspend;
|
|
|
|
Compositor::reinitialize();
|
|
|
|
}
|
|
|
|
|
|
|
|
void X11Compositor::configChanged()
|
|
|
|
{
|
|
|
|
if (m_suspended) {
|
|
|
|
stop();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
Compositor::configChanged();
|
|
|
|
}
|
|
|
|
|
|
|
|
void X11Compositor::suspend(X11Compositor::SuspendReason reason)
|
|
|
|
{
|
|
|
|
Q_ASSERT(reason != NoReasonSuspend);
|
|
|
|
m_suspended |= reason;
|
2019-08-08 12:34:22 +00:00
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
if (reason & ScriptSuspend) {
|
2019-08-08 12:34:22 +00:00
|
|
|
// When disabled show a shortcut how the user can get back compositing.
|
|
|
|
const auto shortcuts = KGlobalAccel::self()->shortcut(
|
|
|
|
workspace()->findChild<QAction*>(QStringLiteral("Suspend Compositing")));
|
2019-08-07 17:33:20 +00:00
|
|
|
if (!shortcuts.isEmpty()) {
|
2019-08-08 12:34:22 +00:00
|
|
|
// Display notification only if there is the shortcut.
|
|
|
|
const QString message =
|
|
|
|
i18n("Desktop effects have been suspended by another application.<br/>"
|
|
|
|
"You can resume using the '%1' shortcut.",
|
|
|
|
shortcuts.first().toString(QKeySequence::NativeText));
|
2019-08-07 17:33:20 +00:00
|
|
|
KNotification::event(QStringLiteral("compositingsuspendeddbus"), message);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
stop();
|
|
|
|
}
|
|
|
|
|
|
|
|
void X11Compositor::resume(X11Compositor::SuspendReason reason)
|
|
|
|
{
|
|
|
|
Q_ASSERT(reason != NoReasonSuspend);
|
|
|
|
m_suspended &= ~reason;
|
|
|
|
start();
|
|
|
|
}
|
|
|
|
|
|
|
|
void X11Compositor::start()
|
|
|
|
{
|
|
|
|
if (m_suspended) {
|
|
|
|
QStringList reasons;
|
|
|
|
if (m_suspended & UserSuspend) {
|
|
|
|
reasons << QStringLiteral("Disabled by User");
|
|
|
|
}
|
|
|
|
if (m_suspended & BlockRuleSuspend) {
|
|
|
|
reasons << QStringLiteral("Disabled by Window");
|
|
|
|
}
|
|
|
|
if (m_suspended & ScriptSuspend) {
|
|
|
|
reasons << QStringLiteral("Disabled by Script");
|
|
|
|
}
|
|
|
|
qCDebug(KWIN_CORE) << "Compositing is suspended, reason:" << reasons;
|
|
|
|
return;
|
|
|
|
} else if (!kwinApp()->platform()->compositingPossible()) {
|
|
|
|
qCCritical(KWIN_CORE) << "Compositing is not possible";
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (!Compositor::setupStart()) {
|
|
|
|
// Internal setup failed, abort.
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
startupWithWorkspace();
|
|
|
|
}
|
2021-02-03 14:19:55 +00:00
|
|
|
|
|
|
|
void X11Compositor::composite(RenderLoop *renderLoop)
|
2019-08-07 17:33:20 +00:00
|
|
|
{
|
2021-01-26 17:41:23 +00:00
|
|
|
if (scene()->overlayWindow() && !isOverlayWindowVisible()) {
|
2019-08-08 12:34:22 +00:00
|
|
|
// Return since nothing is visible.
|
|
|
|
return;
|
2019-08-07 17:33:20 +00:00
|
|
|
}
|
2021-02-03 14:19:55 +00:00
|
|
|
|
|
|
|
QList<Toplevel *> windows = Workspace::self()->xStackingOrder();
|
2021-02-04 09:07:20 +00:00
|
|
|
QList<SurfaceItemX11 *> dirtyItems;
|
2021-02-03 14:19:55 +00:00
|
|
|
|
|
|
|
// Reset the damage state of each window and fetch the damage region
|
|
|
|
// without waiting for a reply
|
2021-02-04 09:07:20 +00:00
|
|
|
for (Toplevel *window : qAsConst(windows)) {
|
|
|
|
SurfaceItemX11 *surfaceItem = static_cast<SurfaceItemX11 *>(window->surfaceItem());
|
|
|
|
if (surfaceItem->fetchDamage()) {
|
|
|
|
dirtyItems.append(surfaceItem);
|
2021-02-03 14:19:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-02-04 09:07:20 +00:00
|
|
|
if (dirtyItems.count() > 0) {
|
2021-02-03 14:19:55 +00:00
|
|
|
scene()->triggerFence();
|
2021-02-04 09:07:20 +00:00
|
|
|
xcb_flush(kwinApp()->x11Connection());
|
2021-02-03 14:19:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Get the replies
|
2021-02-04 09:07:20 +00:00
|
|
|
for (SurfaceItemX11 *item : qAsConst(dirtyItems)) {
|
|
|
|
item->waitForDamage();
|
2021-02-03 14:19:55 +00:00
|
|
|
}
|
|
|
|
|
2021-04-04 11:45:44 +00:00
|
|
|
if (m_framesToTestForSafety > 0 && (scene()->compositingType() & OpenGLCompositing)) {
|
|
|
|
kwinApp()->platform()->createOpenGLSafePoint(Platform::OpenGLSafePoint::PreFrame);
|
|
|
|
}
|
|
|
|
|
2021-02-03 14:19:55 +00:00
|
|
|
Compositor::composite(renderLoop);
|
2021-04-04 11:45:44 +00:00
|
|
|
|
|
|
|
if (m_framesToTestForSafety > 0) {
|
|
|
|
if (scene()->compositingType() & OpenGLCompositing) {
|
|
|
|
kwinApp()->platform()->createOpenGLSafePoint(Platform::OpenGLSafePoint::PostFrame);
|
|
|
|
}
|
|
|
|
m_framesToTestForSafety--;
|
|
|
|
if (m_framesToTestForSafety == 0 && (scene()->compositingType() & OpenGLCompositing)) {
|
|
|
|
kwinApp()->platform()->createOpenGLSafePoint(Platform::OpenGLSafePoint::PostLastGuardedFrame);
|
|
|
|
}
|
|
|
|
}
|
2019-08-07 17:33:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool X11Compositor::checkForOverlayWindow(WId w) const
|
2012-08-16 19:19:54 +00:00
|
|
|
{
|
2019-09-05 16:06:03 +00:00
|
|
|
if (!scene()) {
|
2019-08-08 12:34:22 +00:00
|
|
|
// No scene, so it cannot be the overlay window.
|
2012-08-16 19:19:54 +00:00
|
|
|
return false;
|
|
|
|
}
|
2019-08-07 17:33:20 +00:00
|
|
|
if (!scene()->overlayWindow()) {
|
2019-08-08 12:34:22 +00:00
|
|
|
// No overlay window, it cannot be the overlay.
|
2012-08-16 19:19:54 +00:00
|
|
|
return false;
|
|
|
|
}
|
2019-08-08 12:34:22 +00:00
|
|
|
// Compare the window ID's.
|
2019-08-07 17:33:20 +00:00
|
|
|
return w == scene()->overlayWindow()->window();
|
2012-08-16 19:19:54 +00:00
|
|
|
}
|
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
bool X11Compositor::isOverlayWindowVisible() const
|
2012-08-16 19:19:54 +00:00
|
|
|
{
|
2019-09-05 16:06:03 +00:00
|
|
|
if (!scene()) {
|
2012-08-16 19:19:54 +00:00
|
|
|
return false;
|
|
|
|
}
|
2019-08-07 17:33:20 +00:00
|
|
|
if (!scene()->overlayWindow()) {
|
2012-08-16 19:19:54 +00:00
|
|
|
return false;
|
|
|
|
}
|
2019-08-07 17:33:20 +00:00
|
|
|
return scene()->overlayWindow()->isVisible();
|
|
|
|
}
|
|
|
|
|
2019-09-24 08:48:08 +00:00
|
|
|
void X11Compositor::updateClientCompositeBlocking(X11Client *c)
|
2019-08-07 17:33:20 +00:00
|
|
|
{
|
2019-08-08 12:34:22 +00:00
|
|
|
if (c) {
|
2019-08-07 17:33:20 +00:00
|
|
|
if (c->isBlockingCompositing()) {
|
2019-08-08 12:34:22 +00:00
|
|
|
// Do NOT attempt to call suspend(true) from within the eventchain!
|
|
|
|
if (!(m_suspended & BlockRuleSuspend))
|
2019-09-26 15:09:16 +00:00
|
|
|
QMetaObject::invokeMethod(this, [this]() {
|
|
|
|
suspend(BlockRuleSuspend);
|
|
|
|
}, Qt::QueuedConnection);
|
2019-08-07 17:33:20 +00:00
|
|
|
}
|
|
|
|
}
|
2019-08-08 12:34:22 +00:00
|
|
|
else if (m_suspended & BlockRuleSuspend) {
|
|
|
|
// If !c we just check if we can resume in case a blocking client was lost.
|
2019-09-26 15:09:16 +00:00
|
|
|
bool shouldResume = true;
|
2019-08-08 12:34:22 +00:00
|
|
|
|
Drop some custom list typedefs
Summary:
Qt has its own thing where a type might also have corresponding list
alias, e.g. QObject and QObjectList, QWidget and QWidgetList. I don't
know why Qt does that, maybe for some historical reasons, but what
matters is that we copy this pattern here in KWin. While this pattern
might be useful with some long list types, for example
QList<QWeakPointer<TabBoxClient>> TabBoxClientList
in general, it causes more harm than good. For example, we've got two
new client types, do we need corresponding list typedefs for them? If
no, why do we have ClientList and so on?
Another problem with these typedefs is that you need to include utils.h
header in order to use them. A better way to handle such things is to
just forward declare a client class (if that's possible) and use it
directly with QList or QVector. This way translation units don't get
"bloated" with utils.h stuff for no apparent reason.
So, in order to make code more consistent and easier to follow, this
change drops some of our custom typedefs. Namely ConstClientList,
ClientList, DeletedList, UnmanagedList, ToplevelList, and GroupList.
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24950
2019-10-16 09:11:04 +00:00
|
|
|
for (auto it = Workspace::self()->clientList().constBegin();
|
2019-08-08 12:34:22 +00:00
|
|
|
it != Workspace::self()->clientList().constEnd(); ++it) {
|
2019-08-07 17:33:20 +00:00
|
|
|
if ((*it)->isBlockingCompositing()) {
|
2019-09-26 15:09:16 +00:00
|
|
|
shouldResume = false;
|
2019-08-07 17:33:20 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2019-09-26 15:09:16 +00:00
|
|
|
if (shouldResume) {
|
2019-08-08 12:34:22 +00:00
|
|
|
// Do NOT attempt to call suspend(false) from within the eventchain!
|
2019-09-26 15:09:16 +00:00
|
|
|
QMetaObject::invokeMethod(this, [this]() {
|
|
|
|
resume(BlockRuleSuspend);
|
|
|
|
}, Qt::QueuedConnection);
|
2019-08-07 17:33:20 +00:00
|
|
|
}
|
|
|
|
}
|
2012-08-16 19:19:54 +00:00
|
|
|
}
|
|
|
|
|
[x11] Fix crash during tear down
Summary:
Any call made to a virtual method in constructor/destructor of a base
class won't go to a derived class because the base class may access
uninitialized or destroyed resources.
For example, let's consider the following two classes
class Base {
public:
Base() { foo()->bar(); }
virtual ~Base() { foo()->bar(); }
virtual Foo* foo() const { return nullptr; }
};
class Derived : public Base {
public:
Derived() : mFoo(new Foo) {}
~Derived() override { delete mFoo; }
Foo* foo() const override { return mFoo; }
private:
Foo* mFoo;
};
When an instance of Derived class is created, constructors will run in
the following order:
Base()
Derived()
It's not safe to dispatch foo() method call to Derived class because
constructor of Derived hasn't initialized yet mFoo.
Same story with destructors, they'll run in the following order:
~Derived()
~Base()
It's not safe to dispatch foo() method call in the destructor of Base
class to Derived class because mFoo was deleted.
So, what does that weird C++ behavior has something to do with KWin? Well,
recently Compositor class was split into two classes - WaylandCompositor,
and X11Compositor. Some functionality from X11 doesn't make sense on
Wayland. Therefore methods that implement that stuff were "purified," i.e.
they became pure virtual methods. Unfortunately, when Compositor tears
down it may call pure virtual methods on itself. Given that those calls
cannot be dispatched to X11Compositor or WaylandCompositor, the only
choice that C++ runtime has is to throw an exception.
The fix for this very delicate problem is very simple - do not call virtual
methods from constructors and the destructor. Avoid doing that if you can!
This change moves Compositor::updateClientCompositeBlocking to X11Compositor
so it longer has to be a virtual method. Also, it kind of doesn't make sense
to keep it in base Compositor class because compositing can be blocked only
on X11.
BUG: 411049
Test Plan: KWin no longer crashes when running kwin_x11 --replace command.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: anthonyfieroni, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23098
2019-08-30 16:28:50 +00:00
|
|
|
X11Compositor *X11Compositor::self()
|
|
|
|
{
|
|
|
|
return qobject_cast<X11Compositor *>(Compositor::self());
|
|
|
|
}
|
|
|
|
|
2019-08-08 12:34:22 +00:00
|
|
|
}
|
2019-06-22 10:40:12 +00:00
|
|
|
|
|
|
|
// included for CompositorSelectionOwner
|
|
|
|
#include "composite.moc"
|