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
|
|
|
|
*/
|
2023-08-31 12:23:42 +00:00
|
|
|
#include "compositor.h"
|
2022-03-23 10:13:38 +00:00
|
|
|
|
|
|
|
#include <config-kwin.h>
|
|
|
|
|
2022-08-29 07:55:49 +00:00
|
|
|
#include "core/output.h"
|
|
|
|
#include "core/outputlayer.h"
|
2023-09-21 07:18:13 +00:00
|
|
|
#include "core/renderbackend.h"
|
2022-08-29 07:55:49 +00:00
|
|
|
#include "core/renderlayer.h"
|
|
|
|
#include "core/renderloop.h"
|
2023-11-17 08:50:33 +00:00
|
|
|
#include "cursor.h"
|
2014-06-02 06:51:28 +00:00
|
|
|
#include "dbusinterface.h"
|
2020-09-07 08:11:47 +00:00
|
|
|
#include "ftrace.h"
|
2022-12-19 08:45:29 +00:00
|
|
|
#include "scene/cursorscene.h"
|
2023-08-31 12:44:50 +00:00
|
|
|
#include "scene/surfaceitem.h"
|
2023-09-21 07:18:13 +00:00
|
|
|
#include "scene/workspacescene.h"
|
2022-01-18 08:35:52 +00:00
|
|
|
#include "utils/common.h"
|
2015-03-23 13:29:07 +00:00
|
|
|
#include "wayland_server.h"
|
2019-06-22 10:00:56 +00:00
|
|
|
#include "workspace.h"
|
2007-04-29 17:35:43 +00:00
|
|
|
|
2014-03-17 15:24:10 +00:00
|
|
|
#include <KLocalizedString>
|
2022-02-25 09:38:26 +00:00
|
|
|
#if KWIN_BUILD_NOTIFICATIONS
|
2014-03-17 15:24:10 +00:00
|
|
|
#include <KNotification>
|
2022-02-25 09:38:26 +00:00
|
|
|
#endif
|
2013-01-09 15:03:54 +00:00
|
|
|
|
2007-04-29 17:35:43 +00:00
|
|
|
namespace KWin
|
|
|
|
{
|
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
Compositor *Compositor::s_compositor = nullptr;
|
|
|
|
Compositor *Compositor::self()
|
|
|
|
{
|
|
|
|
return s_compositor;
|
|
|
|
}
|
|
|
|
|
2022-03-23 10:13:38 +00:00
|
|
|
Compositor::Compositor(QObject *workspace)
|
2011-08-21 19:50:23 +00:00
|
|
|
: QObject(workspace)
|
|
|
|
{
|
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_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.
|
2022-11-11 08:46:19 +00:00
|
|
|
QTimer::singleShot(0, this, &Compositor::start);
|
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()
|
|
|
|
{
|
2013-04-26 22:00:23 +00:00
|
|
|
deleteUnusedSupportProperties();
|
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
|
|
|
}
|
|
|
|
|
2022-04-14 12:33:28 +00:00
|
|
|
Output *Compositor::findOutput(RenderLoop *loop) const
|
2022-02-05 13:20:17 +00:00
|
|
|
{
|
2022-07-11 10:41:15 +00:00
|
|
|
const auto outputs = workspace()->outputs();
|
2022-04-14 12:33:28 +00:00
|
|
|
for (Output *output : outputs) {
|
2022-02-05 13:20:17 +00:00
|
|
|
if (output->renderLoop() == loop) {
|
|
|
|
return output;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
2022-02-04 18:38:37 +00:00
|
|
|
void Compositor::addSuperLayer(RenderLayer *layer)
|
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-02-04 18:38:37 +00:00
|
|
|
m_superlayers.insert(layer->loop(), layer);
|
|
|
|
connect(layer->loop(), &RenderLoop::frameRequested, this, &Compositor::handleFrameRequested);
|
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-02-04 18:38:37 +00:00
|
|
|
void Compositor::removeSuperLayer(RenderLayer *layer)
|
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-02-04 18:38:37 +00:00
|
|
|
m_superlayers.remove(layer->loop());
|
|
|
|
disconnect(layer->loop(), &RenderLoop::frameRequested, this, &Compositor::handleFrameRequested);
|
|
|
|
delete layer;
|
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
|
|
|
}
|
|
|
|
|
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()) {
|
2022-10-31 19:02:23 +00:00
|
|
|
for (const xcb_atom_t &atom : std::as_const(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-07-02 20:30:27 +00:00
|
|
|
void Compositor::reinitialize()
|
2011-08-21 19:50:23 +00:00
|
|
|
{
|
|
|
|
// Restart compositing
|
2019-07-04 01:19:18 +00:00
|
|
|
stop();
|
|
|
|
start();
|
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
|
|
|
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
|
|
|
|
2023-02-14 15:05:00 +00:00
|
|
|
uint Compositor::outputFormat(Output *output)
|
|
|
|
{
|
|
|
|
OutputLayer *primaryLayer = m_backend->primaryLayer(output);
|
|
|
|
return primaryLayer->format();
|
|
|
|
}
|
|
|
|
|
2021-07-28 15:14:25 +00:00
|
|
|
void Compositor::composite(RenderLoop *renderLoop)
|
|
|
|
{
|
2021-12-31 11:51:42 +00:00
|
|
|
if (m_backend->checkGraphicsReset()) {
|
|
|
|
qCDebug(KWIN_CORE) << "Graphics reset occurred";
|
2022-02-25 09:38:26 +00:00
|
|
|
#if KWIN_BUILD_NOTIFICATIONS
|
2021-12-31 11:51:42 +00:00
|
|
|
KNotification::event(QStringLiteral("graphicsreset"), i18n("Desktop effects were restarted due to a graphics reset"));
|
2022-02-25 09:38:26 +00:00
|
|
|
#endif
|
2021-12-31 11:51:42 +00:00
|
|
|
reinitialize();
|
|
|
|
return;
|
|
|
|
}
|
2021-07-28 15:14:25 +00:00
|
|
|
|
2022-04-14 12:33:28 +00:00
|
|
|
Output *output = findOutput(renderLoop);
|
2022-12-05 12:29:03 +00:00
|
|
|
OutputLayer *primaryLayer = m_backend->primaryLayer(output);
|
2022-02-05 13:20:17 +00:00
|
|
|
fTraceDuration("Paint (", output->name(), ")");
|
2021-07-28 15:14:25 +00:00
|
|
|
|
2022-02-04 18:38:37 +00:00
|
|
|
RenderLayer *superLayer = m_superlayers[renderLoop];
|
2022-12-05 12:29:03 +00:00
|
|
|
superLayer->setOutputLayer(primaryLayer);
|
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-06-22 12:44:07 +00:00
|
|
|
renderLoop->prepareNewFrame();
|
2023-10-19 14:35:14 +00:00
|
|
|
auto frame = std::make_shared<OutputFrame>(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-06-22 12:44:07 +00:00
|
|
|
if (superLayer->needsRepaint()) {
|
|
|
|
renderLoop->beginPaint();
|
2023-10-19 13:16:56 +00:00
|
|
|
|
|
|
|
QRegion surfaceDamage = primaryLayer->repaints();
|
|
|
|
primaryLayer->resetRepaints();
|
|
|
|
prePaintPass(superLayer, &surfaceDamage);
|
2023-06-22 12:44:07 +00:00
|
|
|
|
|
|
|
SurfaceItem *scanoutCandidate = superLayer->delegate()->scanoutCandidate();
|
|
|
|
renderLoop->setFullscreenSurface(scanoutCandidate);
|
|
|
|
output->setContentType(scanoutCandidate ? scanoutCandidate->contentType() : ContentType::None);
|
|
|
|
|
|
|
|
bool directScanout = false;
|
|
|
|
if (scanoutCandidate) {
|
|
|
|
const auto sublayers = superLayer->sublayers();
|
|
|
|
const bool scanoutPossible = std::none_of(sublayers.begin(), sublayers.end(), [](RenderLayer *sublayer) {
|
|
|
|
return sublayer->isVisible();
|
|
|
|
});
|
|
|
|
if (scanoutPossible && !output->directScanoutInhibited()) {
|
|
|
|
directScanout = primaryLayer->scanout(scanoutCandidate);
|
|
|
|
}
|
2022-01-13 15:11:04 +00:00
|
|
|
}
|
2022-02-04 18:38:37 +00:00
|
|
|
|
2023-06-22 12:44:07 +00:00
|
|
|
if (!directScanout) {
|
|
|
|
if (auto beginInfo = primaryLayer->beginFrame()) {
|
|
|
|
auto &[renderTarget, repaint] = beginInfo.value();
|
2022-04-12 08:16:27 +00:00
|
|
|
|
2023-06-22 12:44:07 +00:00
|
|
|
const QRegion bufferDamage = surfaceDamage.united(repaint).intersected(superLayer->rect().toAlignedRect());
|
2022-02-16 17:13:57 +00:00
|
|
|
|
2023-06-22 12:44:07 +00:00
|
|
|
paintPass(superLayer, renderTarget, bufferDamage);
|
|
|
|
primaryLayer->endFrame(bufferDamage, surfaceDamage);
|
|
|
|
}
|
2022-08-04 16:14:37 +00:00
|
|
|
}
|
2022-02-04 17:38:58 +00:00
|
|
|
|
2023-06-22 12:44:07 +00:00
|
|
|
postPaintPass(superLayer);
|
|
|
|
}
|
2022-02-05 09:47:00 +00:00
|
|
|
|
2023-10-19 14:35:14 +00:00
|
|
|
m_backend->present(output, frame);
|
2022-04-06 12:09:26 +00:00
|
|
|
|
2023-10-19 14:35:14 +00:00
|
|
|
framePass(superLayer, frame.get());
|
2023-06-22 12:44:07 +00:00
|
|
|
|
2022-02-05 09:47:00 +00:00
|
|
|
// TODO: Put it inside the cursor layer once the cursor layer can be backed by a real output layer.
|
|
|
|
if (waylandServer()) {
|
|
|
|
const std::chrono::milliseconds frameTime =
|
2022-03-23 10:13:38 +00:00
|
|
|
std::chrono::duration_cast<std::chrono::milliseconds>(output->renderLoop()->lastPresentationTimestamp());
|
2022-02-05 09:47:00 +00:00
|
|
|
|
|
|
|
if (!Cursors::self()->isCursorHidden()) {
|
|
|
|
Cursor *cursor = Cursors::self()->currentCursor();
|
|
|
|
if (cursor->geometry().intersects(output->geometry())) {
|
|
|
|
cursor->markAsRendered(frameTime);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2022-02-04 18:38:37 +00:00
|
|
|
}
|
|
|
|
|
2023-10-19 14:35:14 +00:00
|
|
|
void Compositor::framePass(RenderLayer *layer, OutputFrame *frame)
|
2023-06-22 12:44:07 +00:00
|
|
|
{
|
2023-10-19 14:35:14 +00:00
|
|
|
layer->delegate()->frame(frame);
|
2023-06-22 12:44:07 +00:00
|
|
|
const auto sublayers = layer->sublayers();
|
|
|
|
for (RenderLayer *sublayer : sublayers) {
|
2023-10-19 14:35:14 +00:00
|
|
|
framePass(sublayer, frame);
|
2023-06-22 12:44:07 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-10-19 13:16:56 +00:00
|
|
|
void Compositor::prePaintPass(RenderLayer *layer, QRegion *damage)
|
2022-02-04 18:38:37 +00:00
|
|
|
{
|
2023-10-19 13:16:56 +00:00
|
|
|
if (const QRegion repaints = layer->repaints(); !repaints.isEmpty()) {
|
|
|
|
*damage += layer->mapToGlobal(repaints);
|
|
|
|
layer->resetRepaints();
|
|
|
|
}
|
|
|
|
|
|
|
|
const QRegion repaints = layer->delegate()->prePaint();
|
|
|
|
if (!repaints.isEmpty()) {
|
|
|
|
*damage += layer->mapToGlobal(repaints);
|
2022-02-04 18:38:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
const auto sublayers = layer->sublayers();
|
|
|
|
for (RenderLayer *sublayer : sublayers) {
|
2023-10-19 13:16:56 +00:00
|
|
|
if (sublayer->isVisible()) {
|
|
|
|
prePaintPass(sublayer, damage);
|
|
|
|
}
|
2022-02-04 18:38:37 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-10-19 13:16:56 +00:00
|
|
|
void Compositor::postPaintPass(RenderLayer *layer)
|
2022-02-04 18:38:37 +00:00
|
|
|
{
|
2023-10-19 13:16:56 +00:00
|
|
|
layer->delegate()->postPaint();
|
2022-02-04 18:38:37 +00:00
|
|
|
const auto sublayers = layer->sublayers();
|
|
|
|
for (RenderLayer *sublayer : sublayers) {
|
|
|
|
if (sublayer->isVisible()) {
|
2023-10-19 13:16:56 +00:00
|
|
|
postPaintPass(sublayer);
|
2022-02-04 18:38:37 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-02-09 17:34:43 +00:00
|
|
|
void Compositor::paintPass(RenderLayer *layer, const RenderTarget &renderTarget, const QRegion ®ion)
|
2022-02-04 18:38:37 +00:00
|
|
|
{
|
2023-02-09 17:34:43 +00:00
|
|
|
layer->delegate()->paint(renderTarget, region);
|
2022-02-04 18:38:37 +00:00
|
|
|
|
|
|
|
const auto sublayers = layer->sublayers();
|
|
|
|
for (RenderLayer *sublayer : sublayers) {
|
|
|
|
if (sublayer->isVisible()) {
|
2023-02-09 17:34:43 +00:00
|
|
|
paintPass(sublayer, renderTarget, region);
|
2022-02-04 18:38:37 +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
|
|
|
|
2022-11-02 18:47:01 +00:00
|
|
|
bool Compositor::compositingPossible() const
|
|
|
|
{
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
QString Compositor::compositingNotPossibleReason() const
|
|
|
|
{
|
|
|
|
return QString();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Compositor::openGLCompositingIsBroken() const
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2023-09-19 08:42:14 +00:00
|
|
|
void Compositor::inhibit(Window *window)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
void Compositor::uninhibit(Window *window)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2023-08-31 12:44:50 +00:00
|
|
|
} // namespace KWin
|
2019-06-22 10:40:12 +00:00
|
|
|
|
2023-08-31 12:23:42 +00:00
|
|
|
#include "moc_compositor.cpp"
|