2020-08-02 22:22:19 +00:00
|
|
|
/*
|
|
|
|
KWin - the KDE window manager
|
|
|
|
This file is part of the KDE project.
|
2011-08-21 19:50:23 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-FileCopyrightText: 2011 Arthur Arlt <a.arlt@stud.uni-heidelberg.de>
|
|
|
|
SPDX-FileCopyrightText: 2012 Martin Gräßlin <mgraesslin@kde.org>
|
2011-08-21 19:50:23 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
*/
|
2019-07-02 18:28:45 +00:00
|
|
|
#pragma once
|
2011-08-21 19:50:23 +00:00
|
|
|
|
2013-04-05 07:41:25 +00:00
|
|
|
#include <kwinglobals.h>
|
2019-07-02 18:28:45 +00:00
|
|
|
|
2013-02-26 08:00:51 +00:00
|
|
|
#include <QObject>
|
|
|
|
#include <QTimer>
|
2011-08-21 19:50:23 +00:00
|
|
|
#include <QRegion>
|
2012-08-17 06:19:38 +00:00
|
|
|
|
2019-07-02 18:28:45 +00:00
|
|
|
namespace KWin
|
|
|
|
{
|
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
|
|
|
|
|
|
|
class AbstractOutput;
|
2019-06-22 10:40:12 +00:00
|
|
|
class CompositorSelectionOwner;
|
2021-11-10 10:34:18 +00:00
|
|
|
class RenderBackend;
|
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
|
|
|
class RenderLoop;
|
2012-08-16 19:19:54 +00:00
|
|
|
class Scene;
|
2021-07-28 15:14:25 +00:00
|
|
|
class Toplevel;
|
2019-09-24 08:48:08 +00:00
|
|
|
class X11Client;
|
2021-06-11 11:11:57 +00:00
|
|
|
class X11SyncManager;
|
2011-08-21 19:50:23 +00:00
|
|
|
|
2019-07-02 18:28:45 +00:00
|
|
|
class KWIN_EXPORT Compositor : public QObject
|
|
|
|
{
|
2011-08-21 19:50:23 +00:00
|
|
|
Q_OBJECT
|
|
|
|
public:
|
2019-07-04 01:19:18 +00:00
|
|
|
enum class State {
|
|
|
|
On = 0,
|
|
|
|
Off,
|
|
|
|
Starting,
|
|
|
|
Stopping
|
|
|
|
};
|
|
|
|
|
2019-07-02 18:28:45 +00:00
|
|
|
~Compositor() override;
|
2019-08-07 17:33:20 +00:00
|
|
|
static Compositor *self();
|
2019-07-02 18:28:45 +00:00
|
|
|
|
2012-08-16 19:19:54 +00:00
|
|
|
/**
|
2019-07-02 18:28:45 +00:00
|
|
|
* Schedules a new repaint if no repaint is currently scheduled.
|
2019-07-29 18:58:33 +00:00
|
|
|
*/
|
2019-07-02 18:28:45 +00:00
|
|
|
void scheduleRepaint();
|
2011-08-21 19:50:23 +00:00
|
|
|
|
2012-08-17 06:18:36 +00:00
|
|
|
/**
|
2019-07-02 18:28:45 +00:00
|
|
|
* Toggles compositing, that is if the Compositor is suspended it will be resumed
|
|
|
|
* and if the Compositor is active it will be suspended.
|
|
|
|
* Invoked by keybinding (shortcut default: Shift + Alt + F12).
|
2019-07-29 18:58:33 +00:00
|
|
|
*/
|
2019-08-07 17:33:20 +00:00
|
|
|
virtual void toggleCompositing() = 0;
|
2019-07-02 18:28:45 +00:00
|
|
|
|
2012-08-17 08:15:33 +00:00
|
|
|
/**
|
|
|
|
* Re-initializes the Compositor completely.
|
|
|
|
* Connected to the D-Bus signal org.kde.KWin /KWin reinitCompositing
|
2019-07-29 18:58:33 +00:00
|
|
|
*/
|
2019-08-07 17:33:20 +00:00
|
|
|
virtual void reinitialize();
|
2019-07-02 18:28:45 +00:00
|
|
|
|
2012-08-23 11:42:59 +00:00
|
|
|
/**
|
2019-07-02 18:28:45 +00:00
|
|
|
* Whether the Compositor is active. That is a Scene is present and the Compositor is
|
|
|
|
* not shutting down itself.
|
2019-07-29 18:58:33 +00:00
|
|
|
*/
|
2019-07-02 18:28:45 +00:00
|
|
|
bool isActive();
|
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
Scene *scene() const {
|
|
|
|
return m_scene;
|
|
|
|
}
|
2021-11-10 10:34:18 +00:00
|
|
|
RenderBackend *backend() const {
|
|
|
|
return m_backend;
|
|
|
|
}
|
2011-08-21 19:50:23 +00:00
|
|
|
|
2019-07-02 18:28:45 +00:00
|
|
|
/**
|
|
|
|
* @brief Static check to test whether the Compositor is available and active.
|
|
|
|
*
|
|
|
|
* @return bool @c true if there is a Compositor and it is active, @c false otherwise
|
2019-07-29 18:58:33 +00:00
|
|
|
*/
|
2019-07-02 18:28:45 +00:00
|
|
|
static bool compositing() {
|
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
|
|
|
return s_compositor != nullptr && s_compositor->isActive();
|
2019-07-02 18:28:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// for delayed supportproperty management of effects
|
|
|
|
void keepSupportProperty(xcb_atom_t atom);
|
|
|
|
void removeSupportProperty(xcb_atom_t atom);
|
2021-07-28 15:14:25 +00:00
|
|
|
QList<Toplevel *> windowsToRender() const;
|
2014-08-27 16:24:43 +00:00
|
|
|
|
2011-08-21 19:50:23 +00:00
|
|
|
Q_SIGNALS:
|
2014-06-02 06:51:28 +00:00
|
|
|
void compositingToggled(bool active);
|
2014-12-03 12:10:35 +00:00
|
|
|
void aboutToDestroy();
|
2019-02-20 13:09:37 +00:00
|
|
|
void aboutToToggleCompositing();
|
2016-04-14 06:51:16 +00:00
|
|
|
void sceneCreated();
|
2011-08-21 19:50:23 +00:00
|
|
|
|
|
|
|
protected:
|
2019-08-07 17:33:20 +00:00
|
|
|
explicit Compositor(QObject *parent = nullptr);
|
2011-08-21 19:50:23 +00:00
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
virtual void start() = 0;
|
2021-06-11 11:11:57 +00:00
|
|
|
virtual void stop();
|
2011-08-21 19:50:23 +00:00
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
/**
|
|
|
|
* @brief Prepares start.
|
|
|
|
* @return bool @c true if start should be continued and @c if not.
|
|
|
|
*/
|
|
|
|
bool setupStart();
|
2015-02-23 14:57:00 +00:00
|
|
|
/**
|
|
|
|
* Continues the startup after Scene And Workspace are created
|
2019-07-29 18:58:33 +00:00
|
|
|
*/
|
2015-02-23 14:57:00 +00:00
|
|
|
void startupWithWorkspace();
|
2019-08-07 17:33:20 +00:00
|
|
|
|
|
|
|
virtual void configChanged();
|
|
|
|
|
|
|
|
void destroyCompositorSelection();
|
|
|
|
|
|
|
|
static Compositor *s_compositor;
|
|
|
|
|
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
|
|
|
protected Q_SLOTS:
|
2021-02-03 14:19:55 +00:00
|
|
|
virtual void 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
|
|
|
|
|
|
|
private Q_SLOTS:
|
2021-02-03 14:19:55 +00:00
|
|
|
void handleFrameRequested(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
|
|
|
void handleOutputEnabled(AbstractOutput *output);
|
|
|
|
void handleOutputDisabled(AbstractOutput *output);
|
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
private:
|
2020-07-20 08:07:08 +00:00
|
|
|
void initializeX11();
|
|
|
|
void cleanupX11();
|
2011-08-21 19:50:23 +00:00
|
|
|
|
2019-07-02 18:28:45 +00:00
|
|
|
void releaseCompositorSelection();
|
|
|
|
void deleteUnusedSupportProperties();
|
|
|
|
|
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 registerRenderLoop(RenderLoop *renderLoop, AbstractOutput *output);
|
|
|
|
void unregisterRenderLoop(RenderLoop *renderLoop);
|
|
|
|
|
2021-11-08 10:08:06 +00:00
|
|
|
bool attemptOpenGLCompositing();
|
|
|
|
bool attemptQPainterCompositing();
|
|
|
|
|
2019-07-04 01:19:18 +00:00
|
|
|
State m_state;
|
2013-01-09 15:03:54 +00:00
|
|
|
|
2019-06-22 10:40:12 +00:00
|
|
|
CompositorSelectionOwner *m_selectionOwner;
|
2012-10-14 10:18:35 +00:00
|
|
|
QTimer m_releaseSelectionTimer;
|
2013-04-26 22:00:23 +00:00
|
|
|
QList<xcb_atom_t> m_unusedSupportProperties;
|
|
|
|
QTimer m_unusedSupportPropertyTimer;
|
2012-08-16 19:19:54 +00:00
|
|
|
Scene *m_scene;
|
2021-11-10 10:34:18 +00:00
|
|
|
RenderBackend *m_backend = nullptr;
|
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
|
|
|
QMap<RenderLoop *, AbstractOutput *> m_renderLoops;
|
2019-08-07 17:33:20 +00:00
|
|
|
};
|
2012-08-28 17:31:17 +00:00
|
|
|
|
2021-06-12 08:03:19 +00:00
|
|
|
class KWIN_EXPORT WaylandCompositor final : public Compositor
|
2019-08-07 17:33:20 +00:00
|
|
|
{
|
|
|
|
Q_OBJECT
|
|
|
|
public:
|
|
|
|
static WaylandCompositor *create(QObject *parent = nullptr);
|
2021-06-12 08:03:19 +00:00
|
|
|
~WaylandCompositor() override;
|
2019-08-07 17:33:20 +00:00
|
|
|
|
|
|
|
void toggleCompositing() override;
|
|
|
|
|
|
|
|
protected:
|
|
|
|
void start() override;
|
|
|
|
|
|
|
|
private:
|
|
|
|
explicit WaylandCompositor(QObject *parent);
|
|
|
|
};
|
|
|
|
|
2021-06-12 08:03:19 +00:00
|
|
|
class KWIN_EXPORT X11Compositor final : public Compositor
|
2019-08-07 17:33:20 +00:00
|
|
|
{
|
|
|
|
Q_OBJECT
|
|
|
|
public:
|
|
|
|
enum SuspendReason {
|
|
|
|
NoReasonSuspend = 0,
|
|
|
|
UserSuspend = 1 << 0,
|
|
|
|
BlockRuleSuspend = 1 << 1,
|
|
|
|
ScriptSuspend = 1 << 2,
|
|
|
|
AllReasonSuspend = 0xff
|
|
|
|
};
|
|
|
|
Q_DECLARE_FLAGS(SuspendReasons, SuspendReason)
|
2019-09-26 15:09:16 +00:00
|
|
|
Q_ENUM(SuspendReason)
|
|
|
|
Q_FLAG(SuspendReasons)
|
2019-08-07 17:33:20 +00:00
|
|
|
|
|
|
|
static X11Compositor *create(QObject *parent = nullptr);
|
2021-06-12 08:03:19 +00:00
|
|
|
~X11Compositor() override;
|
2019-08-07 17:33:20 +00:00
|
|
|
|
2021-06-11 11:11:57 +00:00
|
|
|
X11SyncManager *syncManager() const;
|
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
/**
|
|
|
|
* @brief Suspends the Compositor if it is currently active.
|
|
|
|
*
|
|
|
|
* Note: it is possible that the Compositor is not able to suspend. Use isActive to check
|
|
|
|
* whether the Compositor has been suspended.
|
|
|
|
*
|
|
|
|
* @return void
|
|
|
|
* @see resume
|
|
|
|
* @see isActive
|
2019-08-30 20:30:42 +00:00
|
|
|
*/
|
2019-09-26 15:09:16 +00:00
|
|
|
void suspend(SuspendReason reason);
|
2019-08-07 17:33:20 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @brief Resumes the Compositor if it is currently suspended.
|
|
|
|
*
|
|
|
|
* Note: it is possible that the Compositor cannot be resumed, that is there might be Clients
|
|
|
|
* blocking the usage of Compositing or the Scene might be broken. Use isActive to check
|
|
|
|
* whether the Compositor has been resumed. Also check isCompositingPossible and
|
|
|
|
* isOpenGLBroken.
|
|
|
|
*
|
|
|
|
* Note: The starting of the Compositor can require some time and is partially done threaded.
|
|
|
|
* After this method returns the setup may not have been completed.
|
|
|
|
*
|
|
|
|
* @return void
|
|
|
|
* @see suspend
|
|
|
|
* @see isActive
|
|
|
|
* @see isCompositingPossible
|
|
|
|
* @see isOpenGLBroken
|
2019-08-30 20:30:42 +00:00
|
|
|
*/
|
2019-09-26 15:09:16 +00:00
|
|
|
void resume(SuspendReason reason);
|
2019-08-07 17:33:20 +00:00
|
|
|
|
|
|
|
void toggleCompositing() override;
|
|
|
|
void reinitialize() override;
|
|
|
|
|
|
|
|
void configChanged() override;
|
|
|
|
|
2019-09-05 07:51:47 +00:00
|
|
|
/**
|
|
|
|
* Checks whether @p w is the Scene's overlay window.
|
|
|
|
*/
|
|
|
|
bool checkForOverlayWindow(WId w) const;
|
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
/**
|
|
|
|
* @returns Whether the Scene's Overlay X Window is visible.
|
2019-08-30 20:30:42 +00:00
|
|
|
*/
|
2019-08-07 17:33:20 +00:00
|
|
|
bool isOverlayWindowVisible() const;
|
|
|
|
|
2019-09-24 08:48:08 +00:00
|
|
|
void updateClientCompositeBlocking(X11Client *client = nullptr);
|
[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
|
|
|
|
|
|
|
static X11Compositor *self();
|
2019-08-07 17:33:20 +00:00
|
|
|
|
|
|
|
protected:
|
|
|
|
void start() override;
|
2021-06-11 11:11:57 +00:00
|
|
|
void stop() override;
|
2021-02-03 14:19:55 +00:00
|
|
|
void composite(RenderLoop *renderLoop) override;
|
2019-08-07 17:33:20 +00:00
|
|
|
|
|
|
|
private:
|
|
|
|
explicit X11Compositor(QObject *parent);
|
2021-06-11 11:11:57 +00:00
|
|
|
QScopedPointer<X11SyncManager> m_syncManager;
|
2019-08-07 17:33:20 +00:00
|
|
|
/**
|
|
|
|
* Whether the Compositor is currently suspended, 8 bits encoding the reason
|
2019-08-30 20:30:42 +00:00
|
|
|
*/
|
2019-08-07 17:33:20 +00:00
|
|
|
SuspendReasons m_suspended;
|
2021-04-04 11:45:44 +00:00
|
|
|
int m_framesToTestForSafety = 3;
|
2011-08-21 19:50:23 +00:00
|
|
|
};
|
|
|
|
|
2019-07-02 18:28:45 +00:00
|
|
|
}
|