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;
|
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;
|
2019-09-24 08:48:08 +00:00
|
|
|
class X11Client;
|
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
|
|
|
|
2011-08-21 19:50:23 +00:00
|
|
|
// when adding repaints caused by a window, you probably want to use
|
|
|
|
// either Toplevel::addRepaint() or Toplevel::addWorkspaceRepaint()
|
|
|
|
void addRepaint(const QRect& r);
|
|
|
|
void addRepaint(const QRegion& r);
|
|
|
|
void addRepaint(int x, int y, int w, int h);
|
2019-07-02 18:28:45 +00:00
|
|
|
void addRepaintFull();
|
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;
|
|
|
|
}
|
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);
|
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;
|
2019-07-04 01:19:18 +00:00
|
|
|
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:
|
|
|
|
virtual void handleFrameRequested(RenderLoop *renderLoop);
|
|
|
|
|
|
|
|
private Q_SLOTS:
|
|
|
|
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
|
|
|
int screenForRenderLoop(RenderLoop *renderLoop) const;
|
|
|
|
void registerRenderLoop(RenderLoop *renderLoop, AbstractOutput *output);
|
|
|
|
void unregisterRenderLoop(RenderLoop *renderLoop);
|
|
|
|
|
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;
|
[platformx/x11] Add a freeze protection against OpenGL
Summary:
With nouveau driver it can happen that KWin gets frozen when first trying
to render with OpenGL. This results in a freeze of the complete desktop
as the compositor is non functional.
Our OpenGL breakage detection is only able to detect crashes, but not
freezes. This change improves it by also added a freeze protection.
In the PreInit stage a thread is started with a QTimer of 15 sec. If the
timer fires, qFatal is triggered to terminate KWin. This can only happen
if the creation of the OpenGL compositor takes longer than said 15 sec.
In the PostInit stage the timer gets deleted and the thread stopeed
again.
Thus if a freeze is detected the OpenGL unsafe protection is written into
the config. KWin aborts and gets restarted by DrKonqui. The new KWin
instance will no longer try to activate the freezing OpenGL as the
protection is set.
If KWin doesn't freeze the protection is removed from the config as
we are used to.
Check for freezes for the first n frames, not just the first
This patch changes the freeze detection code to detect freezes in the
first 30 frames (by default, users can change that with the
KWIN_MAX_FRAMES_TESTED environment variable). This detects
successfully the freezes associated to nouveau drivers
in https://bugzilla.suse.com/show_bug.cgi?id=1005323
Reviewers: davidedmundson, #plasma, #kwin, graesslin
Reviewed By: #plasma, #kwin, graesslin
Subscribers: luebking, graesslin, kwin, plasma-devel, davidedmundson
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3132
2016-10-24 15:14:32 +00:00
|
|
|
int m_framesToTestForSafety = 3;
|
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
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
class KWIN_EXPORT WaylandCompositor : public Compositor
|
|
|
|
{
|
|
|
|
Q_OBJECT
|
|
|
|
public:
|
|
|
|
static WaylandCompositor *create(QObject *parent = nullptr);
|
|
|
|
|
|
|
|
void toggleCompositing() override;
|
|
|
|
|
|
|
|
protected:
|
|
|
|
void start() override;
|
|
|
|
|
|
|
|
private:
|
|
|
|
explicit WaylandCompositor(QObject *parent);
|
|
|
|
};
|
|
|
|
|
|
|
|
class KWIN_EXPORT X11Compositor : public Compositor
|
|
|
|
{
|
|
|
|
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);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @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;
|
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 handleFrameRequested(RenderLoop *renderLoop) override;
|
2019-08-07 17:33:20 +00:00
|
|
|
|
|
|
|
private:
|
|
|
|
explicit X11Compositor(QObject *parent);
|
|
|
|
/**
|
|
|
|
* 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;
|
2011-08-21 19:50:23 +00:00
|
|
|
};
|
|
|
|
|
2019-07-02 18:28:45 +00:00
|
|
|
}
|