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
|
|
|
|
2023-11-16 08:56:19 +00:00
|
|
|
#include "libkwineffects/globals.h"
|
2023-05-12 14:23:14 +00:00
|
|
|
#include <xcb/xcb.h>
|
2019-07-02 18:28:45 +00:00
|
|
|
|
2013-02-26 08:00:51 +00:00
|
|
|
#include <QObject>
|
2011-08-21 19:50:23 +00:00
|
|
|
#include <QRegion>
|
2022-03-23 10:13:38 +00:00
|
|
|
#include <QTimer>
|
2022-06-22 10:33:32 +00:00
|
|
|
#include <memory>
|
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
|
|
|
|
2022-04-14 12:33:28 +00:00
|
|
|
class Output;
|
2022-12-19 08:45:29 +00:00
|
|
|
class CursorScene;
|
2021-11-10 10:34:18 +00:00
|
|
|
class RenderBackend;
|
2022-02-04 18:38:37 +00:00
|
|
|
class RenderLayer;
|
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;
|
2022-04-12 08:16:27 +00:00
|
|
|
class RenderTarget;
|
2022-12-18 21:56:41 +00:00
|
|
|
class WorkspaceScene;
|
2023-09-19 08:42:14 +00:00
|
|
|
class Window;
|
2023-10-19 14:35:14 +00:00
|
|
|
class OutputFrame;
|
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-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();
|
|
|
|
|
2022-12-18 21:56:41 +00:00
|
|
|
WorkspaceScene *scene() const
|
2022-03-23 10:13:38 +00:00
|
|
|
{
|
2022-06-22 10:33:32 +00:00
|
|
|
return m_scene.get();
|
2019-08-07 17:33:20 +00:00
|
|
|
}
|
2022-12-19 08:45:29 +00:00
|
|
|
CursorScene *cursorScene() const
|
|
|
|
{
|
|
|
|
return m_cursorScene.get();
|
|
|
|
}
|
2022-03-23 10:13:38 +00:00
|
|
|
RenderBackend *backend() const
|
|
|
|
{
|
2022-06-22 10:33:32 +00:00
|
|
|
return m_backend.get();
|
2021-11-10 10:34:18 +00:00
|
|
|
}
|
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
|
|
|
*/
|
2022-03-23 10:13:38 +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);
|
2014-08-27 16:24:43 +00:00
|
|
|
|
2022-11-02 18:47:01 +00:00
|
|
|
/**
|
|
|
|
* Whether Compositing is possible in the Platform.
|
|
|
|
* Returning @c false in this method makes only sense if requiresCompositing returns @c false.
|
|
|
|
*
|
|
|
|
* The default implementation returns @c true.
|
|
|
|
* @see requiresCompositing
|
|
|
|
*/
|
|
|
|
virtual bool compositingPossible() const;
|
|
|
|
/**
|
|
|
|
* Returns a user facing text explaining why compositing is not possible in case
|
|
|
|
* compositingPossible returns @c false.
|
|
|
|
*
|
|
|
|
* The default implementation returns an empty string.
|
|
|
|
* @see compositingPossible
|
|
|
|
*/
|
|
|
|
virtual QString compositingNotPossibleReason() const;
|
|
|
|
/**
|
|
|
|
* Whether OpenGL compositing is broken.
|
|
|
|
* The Platform can implement this method if it is able to detect whether OpenGL compositing
|
|
|
|
* broke (e.g. triggered a crash in a previous run).
|
|
|
|
*
|
|
|
|
* Default implementation returns @c false.
|
|
|
|
* @see createOpenGLSafePoint
|
|
|
|
*/
|
|
|
|
virtual bool openGLCompositingIsBroken() const;
|
|
|
|
|
2023-02-14 15:05:00 +00:00
|
|
|
/**
|
|
|
|
* @returns the format of the contents in the @p output
|
|
|
|
*
|
|
|
|
* This format is provided using the drm fourcc encoding
|
|
|
|
*/
|
|
|
|
uint outputFormat(Output *output);
|
|
|
|
|
2023-09-19 08:42:14 +00:00
|
|
|
virtual void inhibit(Window *window);
|
|
|
|
virtual void uninhibit(Window *window);
|
|
|
|
|
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;
|
2023-09-21 07:18:13 +00:00
|
|
|
virtual void stop() = 0;
|
2019-08-07 17:33:20 +00:00
|
|
|
|
|
|
|
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
|
|
|
|
2023-09-21 07:18:13 +00:00
|
|
|
protected:
|
2019-07-02 18:28:45 +00:00
|
|
|
void deleteUnusedSupportProperties();
|
|
|
|
|
2022-04-14 12:33:28 +00:00
|
|
|
Output *findOutput(RenderLoop *loop) const;
|
2022-02-04 18:38:37 +00:00
|
|
|
|
|
|
|
void addSuperLayer(RenderLayer *layer);
|
|
|
|
void removeSuperLayer(RenderLayer *layer);
|
|
|
|
|
2023-10-19 13:16:56 +00:00
|
|
|
void prePaintPass(RenderLayer *layer, QRegion *damage);
|
2022-02-04 18:38:37 +00:00
|
|
|
void postPaintPass(RenderLayer *layer);
|
2023-02-09 17:34:43 +00:00
|
|
|
void paintPass(RenderLayer *layer, const RenderTarget &renderTarget, const QRegion ®ion);
|
2023-10-19 14:35:14 +00:00
|
|
|
void framePass(RenderLayer *layer, OutputFrame *frame);
|
2022-02-05 13:20:17 +00:00
|
|
|
|
2022-01-03 08:51:21 +00:00
|
|
|
State m_state = State::Off;
|
2013-04-26 22:00:23 +00:00
|
|
|
QList<xcb_atom_t> m_unusedSupportProperties;
|
|
|
|
QTimer m_unusedSupportPropertyTimer;
|
2022-12-18 21:56:41 +00:00
|
|
|
std::unique_ptr<WorkspaceScene> m_scene;
|
2022-12-19 08:45:29 +00:00
|
|
|
std::unique_ptr<CursorScene> m_cursorScene;
|
2022-06-22 10:33:32 +00:00
|
|
|
std::unique_ptr<RenderBackend> m_backend;
|
2022-02-04 18:38:37 +00:00
|
|
|
QHash<RenderLoop *, RenderLayer *> m_superlayers;
|
2019-08-07 17:33:20 +00:00
|
|
|
};
|
2012-08-28 17:31:17 +00:00
|
|
|
|
2023-08-31 12:44:50 +00:00
|
|
|
} // namespace KWin
|