2020-08-02 22:22:19 +00:00
|
|
|
/*
|
|
|
|
KWin - the KDE window manager
|
|
|
|
This file is part of the KDE project.
|
2010-11-21 13:01:39 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-FileCopyrightText: 2006 Lubos Lunak <l.lunak@kde.org>
|
|
|
|
SPDX-FileCopyrightText: 2012 Martin Gräßlin <mgraesslin@kde.org>
|
2010-11-21 13:01:39 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
Based on glcompmgr code by Felix Bellaby.
|
|
|
|
Using code from Compiz and Beryl.
|
2010-11-21 13:01:39 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
*/
|
2010-11-21 13:01:39 +00:00
|
|
|
|
2012-08-26 15:14:23 +00:00
|
|
|
// own
|
|
|
|
#include "glxbackend.h"
|
2016-04-12 13:03:07 +00:00
|
|
|
#include "logging.h"
|
2017-06-27 19:08:19 +00:00
|
|
|
#include "glx_context_attribute_builder.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 "omlsynccontrolvsyncmonitor.h"
|
|
|
|
#include "sgivideosyncvsyncmonitor.h"
|
|
|
|
#include "softwarevsyncmonitor.h"
|
|
|
|
#include "x11_platform.h"
|
2012-08-26 15:14:23 +00:00
|
|
|
// kwin
|
|
|
|
#include "options.h"
|
|
|
|
#include "overlaywindow.h"
|
2014-08-07 12:16:35 +00:00
|
|
|
#include "composite.h"
|
2017-08-07 15:54: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_p.h"
|
2017-09-08 20:30:18 +00:00
|
|
|
#include "scene.h"
|
2014-11-25 07:40:23 +00:00
|
|
|
#include "screens.h"
|
2014-08-07 12:16:35 +00:00
|
|
|
#include "xcbutils.h"
|
2012-08-26 15:14:23 +00:00
|
|
|
// kwin libs
|
|
|
|
#include <kwinglplatform.h>
|
2017-09-08 20:30:18 +00:00
|
|
|
#include <kwinglutils.h>
|
[libkwineffects] Introduce API to easily show a QtQuick scene in an effect
Summary:
EffectQuickView/Scene is a convenient class to render a QtQuick
scenegraph into an effect.
Current methods (such as present windows) involve creating an underlying
platform window which is expensive, causes a headache to filter out
again in the rest of the code, and only works as an overlay.
The new class exposes things more natively to an effect where we don't
mess with real windows, we can perform the painting anywhere in the view
and we don't have issues with hiding/closing.
QtQuick has both software and hardware accelerated modes, and kwin also
has 3 render backends. Every combination is supported.
* When used in OpenGL mode for both, we render into an FBO export the
texture ID then it's up to the effect to render that into a scene.
* When using software QtQuick rendering we blit into an image, upload
that into a KWinGLTexture which serves as an abstraction layer and
render that into the scene.
* When using GL for QtQuick and XRender/QPainter in kwin everything is
rendered into the internal FBO, blit and exported as an image.
* When using software rendering for both an image gets passed directly.
Mouse and keyboard events can be forwarded, only if the effect
intercepts them.
The class is meant to be generic enough that we can remove all the
QtQuick code from Aurorae.
The intention is also to replace EffectFrameImpl using this backend and
we can kill all of the EffectFrame code throughout the scenes.
The close button in present windows will also be ported to this,
simplifiying that code base.
Classes that handle the rendering and handling QML are intentionally
split so that in the future we can have a declarative effects API create
overlays from within the same context. Similar to how one can
instantiate windows from a typical QML scene.
Notes:
I don't like how I pass the kwin GL context from the backends into the
effect, but I need something that works with the library separation. It
also currently has wayland problem if I create a QOpenGLContext before
the QPA is set up with a scene - but I don't have anything better?
I know for the EffectFrame we need an API to push things through the
effects stack to handle blur/invert etc. Will deal with that when we
port the EffectFrame.
Test Plan: Used in an effect
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24215
2019-09-27 15:06:37 +00:00
|
|
|
#include <kwineffectquickview.h>
|
2014-04-13 18:47:58 +00:00
|
|
|
#include <kwinxrenderutils.h>
|
2013-09-02 11:14:39 +00:00
|
|
|
// Qt
|
2020-01-09 17:05:36 +00:00
|
|
|
#include <QDebug>
|
Better handling for making the compositing OpenGL context current
With QtQuick2 it's possible that the scene graph rendering context either
lives in an own thread or uses the main GUI thread. In the latter case
it's the same thread as our compositing OpenGL context lives in. This
means our basic assumption that between two rendering passes the context
stays current does not hold.
The code already ensured that before we start a rendering pass the
context is made current, but there are many more possible cases. If we
use OpenGL in areas not triggered by the rendering loop but in response
to other events the context needs to be made current. This includes the
loading and unloading of effects (some effects use OpenGL in the static
effect check, in the ctor and dtor), background loading of texture data,
lazy loading after first usage invoked by shortcut, etc. etc.
To properly handle these cases new methods are added to EffectsHandler
to make the compositing OpenGL context current. These calls delegate down
into the scene. On non-OpenGL scenes they are noop, but on OpenGL they go
into the backend and make the context current. In addition they ensure
that Qt doesn't think that it's QOpenGLContext is current by calling
doneCurrent() on the QOpenGLContext::currentContext(). This unfortunately
causes an additional call to makeCurrent with a null context, but there
is no other way to tell Qt - it doesn't notice when a different context
is made current with low level API calls. In the multi-threaded
architecture this doesn't matter as ::currentContext() returns null.
A short evaluation showed that a transition to QOpenGLContext doesn't
seem feasible. Qt only supports either GLX or EGL while KWin supports
both and when entering the transition phase for Wayland, it would become
extremely tricky if our native platform is X11, but we want a Wayland
EGL context. A future solution might be to have a "KWin-QPA plugin" which
uses either xcb or Wayland and hides everything from Qt.
The API documentation is extended to describe when the effects-framework
ensures that an OpenGL context is current. The effects are changed to
make the context current in cases where it's not guaranteed. This has
been done by looking for creation or deletion of GLTextures and Shaders.
If there are other OpenGL usages outside the rendering loop, ctor/dtor
this needs to be changed, too.
2013-11-22 14:05:36 +00:00
|
|
|
#include <QOpenGLContext>
|
2016-11-11 08:59:46 +00:00
|
|
|
#include <QX11Info>
|
[libkwineffects] Introduce API to easily show a QtQuick scene in an effect
Summary:
EffectQuickView/Scene is a convenient class to render a QtQuick
scenegraph into an effect.
Current methods (such as present windows) involve creating an underlying
platform window which is expensive, causes a headache to filter out
again in the rest of the code, and only works as an overlay.
The new class exposes things more natively to an effect where we don't
mess with real windows, we can perform the painting anywhere in the view
and we don't have issues with hiding/closing.
QtQuick has both software and hardware accelerated modes, and kwin also
has 3 render backends. Every combination is supported.
* When used in OpenGL mode for both, we render into an FBO export the
texture ID then it's up to the effect to render that into a scene.
* When using software QtQuick rendering we blit into an image, upload
that into a KWinGLTexture which serves as an abstraction layer and
render that into the scene.
* When using GL for QtQuick and XRender/QPainter in kwin everything is
rendered into the internal FBO, blit and exported as an image.
* When using software rendering for both an image gets passed directly.
Mouse and keyboard events can be forwarded, only if the effect
intercepts them.
The class is meant to be generic enough that we can remove all the
QtQuick code from Aurorae.
The intention is also to replace EffectFrameImpl using this backend and
we can kill all of the EffectFrame code throughout the scenes.
The close button in present windows will also be ported to this,
simplifiying that code base.
Classes that handle the rendering and handling QML are intentionally
split so that in the future we can have a declarative effects API create
overlays from within the same context. Similar to how one can
instantiate windows from a typical QML scene.
Notes:
I don't like how I pass the kwin GL context from the backends into the
effect, but I need something that works with the library separation. It
also currently has wayland problem if I create a QOpenGLContext before
the QPA is set up with a scene - but I don't have anything better?
I know for the EffectFrame we need an API to push things through the
effects stack to handle blur/invert etc. Will deal with that when we
port the EffectFrame.
Test Plan: Used in an effect
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24215
2019-09-27 15:06:37 +00:00
|
|
|
#include <QtPlatformHeaders/QGLXNativeContext>
|
2013-08-29 23:30:13 +00:00
|
|
|
// system
|
|
|
|
#include <unistd.h>
|
2012-08-26 15:14:23 +00:00
|
|
|
|
2014-12-08 21:45:13 +00:00
|
|
|
#include <deque>
|
|
|
|
#include <algorithm>
|
2016-11-22 07:34:59 +00:00
|
|
|
#if HAVE_DL_LIBRARY
|
2016-11-10 15:51:39 +00:00
|
|
|
#include <dlfcn.h>
|
2016-11-22 07:34:59 +00:00
|
|
|
#endif
|
2014-12-08 21:45:13 +00:00
|
|
|
|
2014-09-19 08:04:00 +00:00
|
|
|
#ifndef XCB_GLX_BUFFER_SWAP_COMPLETE
|
|
|
|
#define XCB_GLX_BUFFER_SWAP_COMPLETE 1
|
|
|
|
typedef struct xcb_glx_buffer_swap_complete_event_t {
|
|
|
|
uint8_t response_type; /**< */
|
|
|
|
uint8_t pad0; /**< */
|
|
|
|
uint16_t sequence; /**< */
|
|
|
|
uint16_t event_type; /**< */
|
|
|
|
uint8_t pad1[2]; /**< */
|
|
|
|
xcb_glx_drawable_t drawable; /**< */
|
|
|
|
uint32_t ust_hi; /**< */
|
|
|
|
uint32_t ust_lo; /**< */
|
|
|
|
uint32_t msc_hi; /**< */
|
|
|
|
uint32_t msc_lo; /**< */
|
|
|
|
uint32_t sbc; /**< */
|
|
|
|
} xcb_glx_buffer_swap_complete_event_t;
|
|
|
|
#endif
|
|
|
|
|
2014-04-13 18:47:58 +00:00
|
|
|
#include <tuple>
|
2014-08-07 12:16:35 +00:00
|
|
|
|
2012-08-26 15:14:23 +00:00
|
|
|
namespace KWin
|
|
|
|
{
|
2014-08-07 12:16:35 +00:00
|
|
|
|
2015-01-08 06:12:20 +00:00
|
|
|
SwapEventFilter::SwapEventFilter(xcb_drawable_t drawable, xcb_glx_drawable_t glxDrawable)
|
2014-08-07 12:16:35 +00:00
|
|
|
: X11EventFilter(Xcb::Extensions::self()->glxEventBase() + XCB_GLX_BUFFER_SWAP_COMPLETE),
|
2015-01-08 06:12:20 +00:00
|
|
|
m_drawable(drawable),
|
|
|
|
m_glxDrawable(glxDrawable)
|
2014-08-07 12:16:35 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
bool SwapEventFilter::event(xcb_generic_event_t *event)
|
|
|
|
{
|
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 xcb_glx_buffer_swap_complete_event_t *swapEvent =
|
2014-08-07 12:16:35 +00:00
|
|
|
reinterpret_cast<xcb_glx_buffer_swap_complete_event_t *>(event);
|
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
|
|
|
if (swapEvent->drawable != m_drawable && swapEvent->drawable != m_glxDrawable) {
|
|
|
|
return false;
|
2014-08-07 12:16:35 +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
|
|
|
// The clock for the UST timestamp is left unspecified in the spec, however, usually,
|
|
|
|
// it's CLOCK_MONOTONIC, so no special conversions are needed.
|
|
|
|
const std::chrono::microseconds timestamp((uint64_t(swapEvent->ust_hi) << 32) | swapEvent->ust_lo);
|
2014-08-07 12:16:35 +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
|
|
|
RenderLoopPrivate *renderLoopPrivate = RenderLoopPrivate::get(kwinApp()->platform()->renderLoop());
|
|
|
|
renderLoopPrivate->notifyFrameCompleted(timestamp);
|
2014-08-07 12:16:35 +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
|
|
|
return true;
|
|
|
|
}
|
2014-08-07 12:16:35 +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
|
|
|
GlxBackend::GlxBackend(Display *display, X11StandalonePlatform *backend)
|
2012-08-26 15:14:23 +00:00
|
|
|
: OpenGLBackend()
|
2017-08-07 15:54:56 +00:00
|
|
|
, m_overlayWindow(kwinApp()->platform()->createOverlayWindow())
|
2013-03-11 15:27:24 +00:00
|
|
|
, window(None)
|
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
|
|
|
, fbconfig(nullptr)
|
2013-03-11 15:27:24 +00:00
|
|
|
, glxWindow(None)
|
2013-07-22 13:39:54 +00:00
|
|
|
, ctx(nullptr)
|
2013-11-21 09:44:06 +00:00
|
|
|
, m_bufferAge(0)
|
2016-11-11 08:59:46 +00:00
|
|
|
, m_x11Display(display)
|
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
|
|
|
, m_backend(backend)
|
2012-08-26 15:14:23 +00:00
|
|
|
{
|
2019-01-22 19:36:15 +00:00
|
|
|
// Force initialization of GLX integration in the Qt's xcb backend
|
|
|
|
// to make it call XESetWireToEvent callbacks, which is required
|
|
|
|
// by Mesa when using DRI2.
|
|
|
|
QOpenGLContext::supportsThreadedOpenGL();
|
2012-08-26 15:14:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
GlxBackend::~GlxBackend()
|
|
|
|
{
|
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
|
|
|
delete m_vsyncMonitor;
|
|
|
|
|
|
|
|
// No completion events will be received for in-flight frames, this may lock the
|
|
|
|
// render loop. We need to ensure that the render loop is back to its initial state
|
|
|
|
// if the render backend is about to be destroyed.
|
|
|
|
RenderLoopPrivate::get(kwinApp()->platform()->renderLoop())->invalidate();
|
|
|
|
|
2013-06-19 10:26:34 +00:00
|
|
|
if (isFailed()) {
|
|
|
|
m_overlayWindow->destroy();
|
|
|
|
}
|
2012-08-26 15:14:23 +00:00
|
|
|
// TODO: cleanup in error case
|
|
|
|
// do cleanup after initBuffer()
|
|
|
|
cleanupGL();
|
Better handling for making the compositing OpenGL context current
With QtQuick2 it's possible that the scene graph rendering context either
lives in an own thread or uses the main GUI thread. In the latter case
it's the same thread as our compositing OpenGL context lives in. This
means our basic assumption that between two rendering passes the context
stays current does not hold.
The code already ensured that before we start a rendering pass the
context is made current, but there are many more possible cases. If we
use OpenGL in areas not triggered by the rendering loop but in response
to other events the context needs to be made current. This includes the
loading and unloading of effects (some effects use OpenGL in the static
effect check, in the ctor and dtor), background loading of texture data,
lazy loading after first usage invoked by shortcut, etc. etc.
To properly handle these cases new methods are added to EffectsHandler
to make the compositing OpenGL context current. These calls delegate down
into the scene. On non-OpenGL scenes they are noop, but on OpenGL they go
into the backend and make the context current. In addition they ensure
that Qt doesn't think that it's QOpenGLContext is current by calling
doneCurrent() on the QOpenGLContext::currentContext(). This unfortunately
causes an additional call to makeCurrent with a null context, but there
is no other way to tell Qt - it doesn't notice when a different context
is made current with low level API calls. In the multi-threaded
architecture this doesn't matter as ::currentContext() returns null.
A short evaluation showed that a transition to QOpenGLContext doesn't
seem feasible. Qt only supports either GLX or EGL while KWin supports
both and when entering the transition phase for Wayland, it would become
extremely tricky if our native platform is X11, but we want a Wayland
EGL context. A future solution might be to have a "KWin-QPA plugin" which
uses either xcb or Wayland and hides everything from Qt.
The API documentation is extended to describe when the effects-framework
ensures that an OpenGL context is current. The effects are changed to
make the context current in cases where it's not guaranteed. This has
been done by looking for creation or deletion of GLTextures and Shaders.
If there are other OpenGL usages outside the rendering loop, ctor/dtor
this needs to be changed, too.
2013-11-22 14:05:36 +00:00
|
|
|
doneCurrent();
|
[libkwineffects] Introduce API to easily show a QtQuick scene in an effect
Summary:
EffectQuickView/Scene is a convenient class to render a QtQuick
scenegraph into an effect.
Current methods (such as present windows) involve creating an underlying
platform window which is expensive, causes a headache to filter out
again in the rest of the code, and only works as an overlay.
The new class exposes things more natively to an effect where we don't
mess with real windows, we can perform the painting anywhere in the view
and we don't have issues with hiding/closing.
QtQuick has both software and hardware accelerated modes, and kwin also
has 3 render backends. Every combination is supported.
* When used in OpenGL mode for both, we render into an FBO export the
texture ID then it's up to the effect to render that into a scene.
* When using software QtQuick rendering we blit into an image, upload
that into a KWinGLTexture which serves as an abstraction layer and
render that into the scene.
* When using GL for QtQuick and XRender/QPainter in kwin everything is
rendered into the internal FBO, blit and exported as an image.
* When using software rendering for both an image gets passed directly.
Mouse and keyboard events can be forwarded, only if the effect
intercepts them.
The class is meant to be generic enough that we can remove all the
QtQuick code from Aurorae.
The intention is also to replace EffectFrameImpl using this backend and
we can kill all of the EffectFrame code throughout the scenes.
The close button in present windows will also be ported to this,
simplifiying that code base.
Classes that handle the rendering and handling QML are intentionally
split so that in the future we can have a declarative effects API create
overlays from within the same context. Similar to how one can
instantiate windows from a typical QML scene.
Notes:
I don't like how I pass the kwin GL context from the backends into the
effect, but I need something that works with the library separation. It
also currently has wayland problem if I create a QOpenGLContext before
the QPA is set up with a scene - but I don't have anything better?
I know for the EffectFrame we need an API to push things through the
effects stack to handle blur/invert etc. Will deal with that when we
port the EffectFrame.
Test Plan: Used in an effect
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24215
2019-09-27 15:06:37 +00:00
|
|
|
EffectQuickView::setShareContext(nullptr);
|
2013-03-11 15:27:24 +00:00
|
|
|
|
2013-03-11 15:05:47 +00:00
|
|
|
if (ctx)
|
|
|
|
glXDestroyContext(display(), ctx);
|
2013-03-11 15:27:24 +00:00
|
|
|
|
|
|
|
if (glxWindow)
|
|
|
|
glXDestroyWindow(display(), glxWindow);
|
|
|
|
|
|
|
|
if (window)
|
|
|
|
XDestroyWindow(display(), window);
|
|
|
|
|
Reintroduce the useage of FBConfigInfo* hash in glxbackend
The hash was completely useless as we never inserted created
FBConfigInfo* into the hash. This change fixes the usage of the
hash and also ensures that it doesn't leak by deleting all hash
elements on tear down.
Current memleak backtrace from ASAN:
Direct leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x4dc932 in operator new(unsigned long) (/home/kfunk/devel/install/kf5/bin/kwin_x11+0x4dc932)
#1 0x7f3c596de0f3 in KWin::GlxBackend::infoForVisual(unsigned int) /home/kfunk/devel/src/kf5/kwin/glxbackend.cpp:454:12
#2 0x7f3c596e7ef4 in KWin::GlxTexture::loadTexture(unsigned int, QSize const&, unsigned int) /home/kfunk/devel/src/kf5/kwin/glxbackend.cpp:826:32
#3 0x7f3c596e921e in KWin::GlxTexture::loadTexture(KWin::WindowPixmap*) /home/kfunk/devel/src/kf5/kwin/glxbackend.cpp:869:12
#4 0x7f3c5916e895 in KWin::SceneOpenGL::Texture::load(KWin::WindowPixmap*) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1232:12
#5 0x7f3c5917019a in KWin::OpenGLWindowPixmap::bind() /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1681:20
#6 0x7f3c5916fce0 in KWin::SceneOpenGL::Window::bindTexture() /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1288:12
#7 0x7f3c5917294b in KWin::SceneOpenGL::Window::beginRenderWindow(int, QRegion const&, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1349:10
#8 0x7f3c59176f24 in KWin::SceneOpenGL2Window::performPaint(int, QRegion, KWin::WindowPaintData) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1510:10
#9 0x7f3c5916d410 in KWin::SceneOpenGL2::performPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1161:9
#10 0x7f3c5916cbc9 in KWin::SceneOpenGL2::finalDrawWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1147:9
#11 0x7f3c5922e92f in KWin::EffectsHandlerImpl::drawWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/effects.cpp:502:9
#12 0x7f3c590d7bc5 in KWin::Scene::finalPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene.cpp:606:5
#13 0x7f3c5922c979 in KWin::EffectsHandlerImpl::paintWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/effects.cpp:465:9
#14 0x7f3c590d2b38 in KWin::Scene::paintWindow(KWin::Scene::Window*, int, QRegion, KWin::WindowQuadList) /home/kfunk/devel/src/kf5/kwin/scene.cpp:478:5
#15 0x7f3c590ced89 in KWin::Scene::paintSimpleScreen(int, QRegion) /home/kfunk/devel/src/kf5/kwin/scene.cpp:381:9
#16 0x7f3c5916b2b1 in KWin::SceneOpenGL2::paintSimpleScreen(int, QRegion) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1098:12
#17 0x7f3c590c8bd3 in KWin::Scene::finalPaintScreen(int, QRegion, KWin::ScreenPaintData&) /home/kfunk/devel/src/kf5/kwin/scene.cpp:200:9
#18 0x7f3c5922b062 in KWin::EffectsHandlerImpl::paintScreen(int, QRegion, KWin::ScreenPaintData&) /home/kfunk/devel/src/kf5/kwin/effects.cpp:422:9
#19 0x7f3c590c791f in KWin::Scene::paintScreen(int*, QRegion const&, QRegion const&, QRegion*, QRegion*, QMatrix4x4 const&) /home/kfunk/devel/src/kf5/kwin/scene.cpp:150:5
#20 0x7f3c5915e500 in KWin::SceneOpenGL::paint(QRegion, QList<KWin::Toplevel*>) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:751:9
#21 0x7f3c5907ea3c in KWin::Compositor::performCompositing() /home/kfunk/devel/src/kf5/kwin/composite.cpp:726:29
#22 0x7f3c5907c230 in KWin::Compositor::startupWithWorkspace() /home/kfunk/devel/src/kf5/kwin/composite.cpp:347:5
#23 0x7f3c59079bbb in KWin::Compositor::slotCompositingOptionsInitialized() /home/kfunk/devel/src/kf5/kwin/composite.cpp:283:9
#24 0x7f3c59076084 in KWin::Compositor::setup() /home/kfunk/devel/src/kf5/kwin/composite.cpp:184:9
#25 0x7f3c598b165f in KWin::Compositor::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) /home/kfunk/devel/build/kf5/kwin/moc_composite.cpp:263:18
#26 0x7f3c52de67b0 in QObject::event(QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x2b67b0)
#27 0x7f3c536ab9db in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x15b9db)
REVIEW: 127096
2016-02-17 07:49:02 +00:00
|
|
|
qDeleteAll(m_fbconfigHash);
|
|
|
|
m_fbconfigHash.clear();
|
|
|
|
|
2013-03-11 15:27:24 +00:00
|
|
|
overlayWindow()->destroy();
|
2013-06-19 10:26:34 +00:00
|
|
|
delete m_overlayWindow;
|
2012-08-26 15:14:23 +00:00
|
|
|
}
|
|
|
|
|
2016-11-10 15:51:39 +00:00
|
|
|
typedef void (*glXFuncPtr)();
|
|
|
|
|
|
|
|
static glXFuncPtr getProcAddress(const char* name)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2016-11-10 15:51:39 +00:00
|
|
|
glXFuncPtr ret = nullptr;
|
|
|
|
#if HAVE_EPOXY_GLX
|
|
|
|
ret = glXGetProcAddress((const GLubyte*) name);
|
|
|
|
#endif
|
2016-11-22 07:34:59 +00:00
|
|
|
#if HAVE_DL_LIBRARY
|
2016-11-10 15:51:39 +00:00
|
|
|
if (ret == nullptr)
|
|
|
|
ret = (glXFuncPtr) dlsym(RTLD_DEFAULT, name);
|
2016-11-22 07:34:59 +00:00
|
|
|
#endif
|
2016-11-10 15:51:39 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
glXSwapIntervalMESA_func glXSwapIntervalMESA;
|
2014-12-08 21:45:13 +00:00
|
|
|
|
2016-11-10 15:51:39 +00:00
|
|
|
void GlxBackend::init()
|
|
|
|
{
|
2014-12-08 21:45:13 +00:00
|
|
|
// Require at least GLX 1.3
|
2016-11-10 14:07:15 +00:00
|
|
|
if (!checkVersion()) {
|
2013-07-23 05:02:52 +00:00
|
|
|
setFailed(QStringLiteral("Requires at least GLX 1.3"));
|
2012-10-03 08:28:43 +00:00
|
|
|
return;
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2014-12-08 21:45:13 +00:00
|
|
|
|
2016-11-10 14:56:36 +00:00
|
|
|
initExtensions();
|
|
|
|
|
2016-11-10 15:51:39 +00:00
|
|
|
// resolve glXSwapIntervalMESA if available
|
|
|
|
if (hasExtension(QByteArrayLiteral("GLX_MESA_swap_control"))) {
|
|
|
|
glXSwapIntervalMESA = (glXSwapIntervalMESA_func) getProcAddress("glXSwapIntervalMESA");
|
|
|
|
} else {
|
|
|
|
glXSwapIntervalMESA = nullptr;
|
|
|
|
}
|
|
|
|
|
2014-12-08 21:45:13 +00:00
|
|
|
initVisualDepthHashTable();
|
|
|
|
|
2012-08-26 15:14:23 +00:00
|
|
|
if (!initBuffer()) {
|
2013-07-23 05:02:52 +00:00
|
|
|
setFailed(QStringLiteral("Could not initialize the buffer"));
|
2012-08-26 15:14:23 +00:00
|
|
|
return;
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2014-12-08 21:45:13 +00:00
|
|
|
|
2012-08-26 15:14:23 +00:00
|
|
|
if (!initRenderingContext()) {
|
2013-07-23 05:02:52 +00:00
|
|
|
setFailed(QStringLiteral("Could not initialize rendering context"));
|
2011-04-28 20:06:21 +00:00
|
|
|
return;
|
|
|
|
}
|
2014-04-13 18:47:58 +00:00
|
|
|
|
2012-08-26 15:14:23 +00:00
|
|
|
// Initialize OpenGL
|
|
|
|
GLPlatform *glPlatform = GLPlatform::instance();
|
2012-09-29 11:19:35 +00:00
|
|
|
glPlatform->detect(GlxPlatformInterface);
|
2013-07-17 13:44:42 +00:00
|
|
|
options->setGlPreferBufferSwap(options->glPreferBufferSwap()); // resolve autosetting
|
|
|
|
if (options->glPreferBufferSwap() == Options::AutoSwapStrategy)
|
|
|
|
options->setGlPreferBufferSwap('e'); // for unknown drivers - should not happen
|
2012-08-26 15:14:23 +00:00
|
|
|
glPlatform->printResults();
|
2016-11-11 08:16:23 +00:00
|
|
|
initGL(&getProcAddress);
|
2013-11-21 09:44:06 +00:00
|
|
|
|
2010-11-21 13:01:39 +00:00
|
|
|
// Check whether certain features are supported
|
2016-11-10 14:56:36 +00:00
|
|
|
m_haveMESACopySubBuffer = hasExtension(QByteArrayLiteral("GLX_MESA_copy_sub_buffer"));
|
|
|
|
m_haveMESASwapControl = hasExtension(QByteArrayLiteral("GLX_MESA_swap_control"));
|
|
|
|
m_haveEXTSwapControl = hasExtension(QByteArrayLiteral("GLX_EXT_swap_control"));
|
2020-01-09 17:18:25 +00:00
|
|
|
m_haveSGISwapControl = hasExtension(QByteArrayLiteral("GLX_SGI_swap_control"));
|
2020-01-09 17:06:12 +00:00
|
|
|
m_haveINTELSwapEvent = hasExtension(QByteArrayLiteral("GLX_INTEL_swap_event"))
|
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
|
|
|
&& qgetenv("KWIN_USE_INTEL_SWAP_EVENT") != QByteArrayLiteral("0");
|
2014-02-11 18:57:06 +00:00
|
|
|
|
2020-11-18 13:49:25 +00:00
|
|
|
bool haveSwapInterval = m_haveMESASwapControl || m_haveEXTSwapControl || m_haveSGISwapControl;
|
2020-01-09 17:18:22 +00:00
|
|
|
|
2013-11-21 09:44:06 +00:00
|
|
|
setSupportsBufferAge(false);
|
|
|
|
|
2016-11-10 14:56:36 +00:00
|
|
|
if (hasExtension(QByteArrayLiteral("GLX_EXT_buffer_age"))) {
|
2013-11-21 09:44:06 +00:00
|
|
|
const QByteArray useBufferAge = qgetenv("KWIN_USE_BUFFER_AGE");
|
|
|
|
|
|
|
|
if (useBufferAge != "0")
|
|
|
|
setSupportsBufferAge(true);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
// If the buffer age extension is unsupported, glXSwapBuffers() is not guaranteed to
|
|
|
|
// be called. Therefore, there is no point for creating the swap event filter.
|
|
|
|
if (!supportsBufferAge()) {
|
|
|
|
m_haveINTELSwapEvent = false;
|
|
|
|
}
|
|
|
|
|
2021-01-07 08:09:47 +00:00
|
|
|
if (haveSwapInterval) {
|
|
|
|
setSwapInterval(1);
|
2013-03-27 10:34:25 +00:00
|
|
|
} else {
|
2021-01-07 08:09:47 +00:00
|
|
|
qCWarning(KWIN_X11STANDALONE) << "glSwapInterval is unsupported";
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2021-01-07 08:09:47 +00:00
|
|
|
|
2012-10-13 08:33:38 +00:00
|
|
|
if (glPlatform->isVirtualBox()) {
|
|
|
|
// VirtualBox does not support glxQueryDrawable
|
|
|
|
// this should actually be in kwinglutils_funcs, but QueryDrawable seems not to be provided by an extension
|
|
|
|
// and the GLPlatform has not been initialized at the moment when initGLX() is called.
|
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
|
|
|
glXQueryDrawable = nullptr;
|
2012-10-13 08:33:38 +00:00
|
|
|
}
|
2013-03-11 15:27:24 +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
|
|
|
if (m_haveINTELSwapEvent) {
|
|
|
|
// Nice, the GLX_INTEL_swap_event extension is available. We are going to receive
|
|
|
|
// the presentation timestamp (UST) after glXSwapBuffers() via the X command stream.
|
|
|
|
m_swapEventFilter = std::make_unique<SwapEventFilter>(window, glxWindow);
|
|
|
|
glXSelectEvent(display(), glxWindow, GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK);
|
|
|
|
} else {
|
|
|
|
// If the GLX_INTEL_swap_event extension is unavailble, we are going to wait for
|
|
|
|
// the next vblank event after swapping buffers. This is a bit racy solution, e.g.
|
|
|
|
// the vblank may occur right in between querying video sync counter and the act
|
|
|
|
// of swapping buffers, but on the other hand, there is no any better alternative
|
|
|
|
// option. NVIDIA doesn't provide any extension such as GLX_INTEL_swap_event.
|
|
|
|
if (!m_vsyncMonitor) {
|
|
|
|
m_vsyncMonitor = SGIVideoSyncVsyncMonitor::create(this);
|
|
|
|
}
|
|
|
|
if (!m_vsyncMonitor) {
|
|
|
|
m_vsyncMonitor = OMLSyncControlVsyncMonitor::create(this);
|
|
|
|
}
|
|
|
|
if (!m_vsyncMonitor) {
|
|
|
|
SoftwareVsyncMonitor *monitor = SoftwareVsyncMonitor::create(this);
|
|
|
|
RenderLoop *renderLoop = m_backend->renderLoop();
|
|
|
|
monitor->setRefreshRate(renderLoop->refreshRate());
|
|
|
|
connect(renderLoop, &RenderLoop::refreshRateChanged, this, [this, monitor]() {
|
|
|
|
monitor->setRefreshRate(m_backend->renderLoop()->refreshRate());
|
|
|
|
});
|
|
|
|
m_vsyncMonitor = monitor;
|
|
|
|
}
|
|
|
|
|
|
|
|
connect(m_vsyncMonitor, &VsyncMonitor::vblankOccurred, this, &GlxBackend::vblank);
|
|
|
|
}
|
|
|
|
|
2013-03-11 15:05:47 +00:00
|
|
|
setIsDirectRendering(bool(glXIsDirect(display(), ctx)));
|
2013-03-11 15:27:24 +00:00
|
|
|
|
2016-04-12 13:03:07 +00:00
|
|
|
qCDebug(KWIN_X11STANDALONE) << "Direct rendering:" << isDirectRendering();
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2010-11-21 13:01:39 +00:00
|
|
|
|
2016-11-10 14:07:15 +00:00
|
|
|
bool GlxBackend::checkVersion()
|
|
|
|
{
|
|
|
|
int major, minor;
|
|
|
|
glXQueryVersion(display(), &major, &minor);
|
|
|
|
return kVersionNumber(major, minor) >= kVersionNumber(1, 3);
|
|
|
|
}
|
|
|
|
|
2016-11-10 14:56:36 +00:00
|
|
|
void GlxBackend::initExtensions()
|
|
|
|
{
|
|
|
|
const QByteArray string = (const char *) glXQueryExtensionsString(display(), QX11Info::appScreen());
|
|
|
|
setExtensions(string.split(' '));
|
|
|
|
}
|
|
|
|
|
2012-08-26 15:14:23 +00:00
|
|
|
bool GlxBackend::initRenderingContext()
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2013-11-05 13:48:40 +00:00
|
|
|
const bool direct = true;
|
2013-03-11 15:19:45 +00:00
|
|
|
|
2013-03-13 15:09:05 +00:00
|
|
|
// Use glXCreateContextAttribsARB() when it's available
|
2016-11-10 14:56:36 +00:00
|
|
|
if (hasExtension(QByteArrayLiteral("GLX_ARB_create_context"))) {
|
|
|
|
const bool have_robustness = hasExtension(QByteArrayLiteral("GLX_ARB_create_context_robustness"));
|
2017-06-22 14:57:21 +00:00
|
|
|
const bool haveVideoMemoryPurge = hasExtension(QByteArrayLiteral("GLX_NV_robustness_video_memory_purge"));
|
2013-05-19 14:28:48 +00:00
|
|
|
|
2017-06-27 19:08:19 +00:00
|
|
|
std::vector<GlxContextAttributeBuilder> candidates;
|
2013-05-19 14:28:48 +00:00
|
|
|
if (options->glCoreProfile()) {
|
2017-06-27 19:08:19 +00:00
|
|
|
if (have_robustness) {
|
2017-06-22 14:57:21 +00:00
|
|
|
if (haveVideoMemoryPurge) {
|
2017-06-27 19:08:19 +00:00
|
|
|
GlxContextAttributeBuilder purgeMemoryCore;
|
|
|
|
purgeMemoryCore.setVersion(3, 1);
|
|
|
|
purgeMemoryCore.setRobust(true);
|
|
|
|
purgeMemoryCore.setResetOnVideoMemoryPurge(true);
|
|
|
|
candidates.emplace_back(std::move(purgeMemoryCore));
|
2017-06-22 14:57:21 +00:00
|
|
|
}
|
2017-06-27 19:08:19 +00:00
|
|
|
GlxContextAttributeBuilder robustCore;
|
|
|
|
robustCore.setVersion(3, 1);
|
|
|
|
robustCore.setRobust(true);
|
|
|
|
candidates.emplace_back(std::move(robustCore));
|
|
|
|
}
|
|
|
|
GlxContextAttributeBuilder core;
|
|
|
|
core.setVersion(3, 1);
|
|
|
|
candidates.emplace_back(std::move(core));
|
|
|
|
} else {
|
|
|
|
if (have_robustness) {
|
|
|
|
if (haveVideoMemoryPurge) {
|
|
|
|
GlxContextAttributeBuilder purgeMemoryLegacy;
|
|
|
|
purgeMemoryLegacy.setRobust(true);
|
|
|
|
purgeMemoryLegacy.setResetOnVideoMemoryPurge(true);
|
|
|
|
candidates.emplace_back(std::move(purgeMemoryLegacy));
|
2017-06-22 14:57:21 +00:00
|
|
|
}
|
2017-06-27 19:08:19 +00:00
|
|
|
GlxContextAttributeBuilder robustLegacy;
|
|
|
|
robustLegacy.setRobust(true);
|
|
|
|
candidates.emplace_back(std::move(robustLegacy));
|
2017-06-22 14:57:21 +00:00
|
|
|
}
|
2017-06-27 19:08:19 +00:00
|
|
|
GlxContextAttributeBuilder legacy;
|
|
|
|
legacy.setVersion(2, 1);
|
|
|
|
candidates.emplace_back(std::move(legacy));
|
2013-05-19 14:28:48 +00:00
|
|
|
}
|
2017-06-27 19:08:19 +00:00
|
|
|
for (auto it = candidates.begin(); it != candidates.end(); it++) {
|
|
|
|
const auto attribs = it->build();
|
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
|
|
|
ctx = glXCreateContextAttribsARB(display(), fbconfig, nullptr, true, attribs.data());
|
2017-06-27 19:08:19 +00:00
|
|
|
if (ctx) {
|
|
|
|
qCDebug(KWIN_X11STANDALONE) << "Created GLX context with attributes:" << &(*it);
|
|
|
|
break;
|
2017-06-22 14:57:21 +00:00
|
|
|
}
|
|
|
|
}
|
2013-03-13 15:09:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!ctx)
|
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
|
|
|
ctx = glXCreateNewContext(display(), fbconfig, GLX_RGBA_TYPE, nullptr, direct);
|
2013-03-11 15:19:45 +00:00
|
|
|
|
|
|
|
if (!ctx) {
|
2016-04-12 13:03:07 +00:00
|
|
|
qCDebug(KWIN_X11STANDALONE) << "Failed to create an OpenGL context.";
|
2013-03-11 15:19:45 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-03-11 15:27:24 +00:00
|
|
|
if (!glXMakeCurrent(display(), glxWindow, ctx)) {
|
2016-04-12 13:03:07 +00:00
|
|
|
qCDebug(KWIN_X11STANDALONE) << "Failed to make the OpenGL context current.";
|
2013-03-11 15:19:45 +00:00
|
|
|
glXDestroyContext(display(), ctx);
|
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
|
|
|
ctx = nullptr;
|
2013-03-11 15:19:45 +00:00
|
|
|
return false;
|
2010-11-21 13:01:39 +00:00
|
|
|
}
|
2013-03-11 15:19:45 +00:00
|
|
|
|
[libkwineffects] Introduce API to easily show a QtQuick scene in an effect
Summary:
EffectQuickView/Scene is a convenient class to render a QtQuick
scenegraph into an effect.
Current methods (such as present windows) involve creating an underlying
platform window which is expensive, causes a headache to filter out
again in the rest of the code, and only works as an overlay.
The new class exposes things more natively to an effect where we don't
mess with real windows, we can perform the painting anywhere in the view
and we don't have issues with hiding/closing.
QtQuick has both software and hardware accelerated modes, and kwin also
has 3 render backends. Every combination is supported.
* When used in OpenGL mode for both, we render into an FBO export the
texture ID then it's up to the effect to render that into a scene.
* When using software QtQuick rendering we blit into an image, upload
that into a KWinGLTexture which serves as an abstraction layer and
render that into the scene.
* When using GL for QtQuick and XRender/QPainter in kwin everything is
rendered into the internal FBO, blit and exported as an image.
* When using software rendering for both an image gets passed directly.
Mouse and keyboard events can be forwarded, only if the effect
intercepts them.
The class is meant to be generic enough that we can remove all the
QtQuick code from Aurorae.
The intention is also to replace EffectFrameImpl using this backend and
we can kill all of the EffectFrame code throughout the scenes.
The close button in present windows will also be ported to this,
simplifiying that code base.
Classes that handle the rendering and handling QML are intentionally
split so that in the future we can have a declarative effects API create
overlays from within the same context. Similar to how one can
instantiate windows from a typical QML scene.
Notes:
I don't like how I pass the kwin GL context from the backends into the
effect, but I need something that works with the library separation. It
also currently has wayland problem if I create a QOpenGLContext before
the QPA is set up with a scene - but I don't have anything better?
I know for the EffectFrame we need an API to push things through the
effects stack to handle blur/invert etc. Will deal with that when we
port the EffectFrame.
Test Plan: Used in an effect
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24215
2019-09-27 15:06:37 +00:00
|
|
|
auto qtContext = new QOpenGLContext;
|
|
|
|
QGLXNativeContext native(ctx, display());
|
|
|
|
qtContext->setNativeHandle(QVariant::fromValue(native));
|
|
|
|
qtContext->create();
|
|
|
|
EffectQuickView::setShareContext(std::unique_ptr<QOpenGLContext>(qtContext));
|
|
|
|
|
2011-01-30 14:34:42 +00:00
|
|
|
return true;
|
|
|
|
}
|
2010-11-21 13:01:39 +00:00
|
|
|
|
2012-08-26 15:14:23 +00:00
|
|
|
bool GlxBackend::initBuffer()
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2013-03-11 15:16:05 +00:00
|
|
|
if (!initFbConfig())
|
2010-11-21 13:01:39 +00:00
|
|
|
return false;
|
2013-03-11 15:16:05 +00:00
|
|
|
|
2013-03-11 15:27:24 +00:00
|
|
|
if (overlayWindow()->create()) {
|
2014-12-08 21:46:31 +00:00
|
|
|
xcb_connection_t * const c = connection();
|
|
|
|
|
2013-03-11 15:27:24 +00:00
|
|
|
// Try to create double-buffered window in the overlay
|
2014-12-08 21:46:31 +00:00
|
|
|
xcb_visualid_t visual;
|
|
|
|
glXGetFBConfigAttrib(display(), fbconfig, GLX_VISUAL_ID, (int *) &visual);
|
|
|
|
|
2013-09-17 16:07:17 +00:00
|
|
|
if (!visual) {
|
2016-04-12 13:03:07 +00:00
|
|
|
qCCritical(KWIN_X11STANDALONE) << "The GLXFBConfig does not have an associated X visual";
|
2013-09-17 16:07:17 +00:00
|
|
|
return false;
|
|
|
|
}
|
2014-12-08 21:46:31 +00:00
|
|
|
|
|
|
|
xcb_colormap_t colormap = xcb_generate_id(c);
|
|
|
|
xcb_create_colormap(c, false, colormap, rootWindow(), visual);
|
|
|
|
|
|
|
|
const QSize size = screens()->size();
|
|
|
|
|
|
|
|
window = xcb_generate_id(c);
|
|
|
|
xcb_create_window(c, visualDepth(visual), window, overlayWindow()->window(),
|
|
|
|
0, 0, size.width(), size.height(), 0, XCB_WINDOW_CLASS_INPUT_OUTPUT,
|
|
|
|
visual, XCB_CW_COLORMAP, &colormap);
|
|
|
|
|
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
|
|
|
glxWindow = glXCreateWindow(display(), fbconfig, window, nullptr);
|
2013-03-11 15:27:24 +00:00
|
|
|
overlayWindow()->setup(window);
|
2011-01-30 14:34:42 +00:00
|
|
|
} else {
|
2016-04-12 13:03:07 +00:00
|
|
|
qCCritical(KWIN_X11STANDALONE) << "Failed to create overlay window";
|
2013-03-11 15:27:24 +00:00
|
|
|
return false;
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2013-03-11 15:27:24 +00:00
|
|
|
|
2010-11-21 13:01:39 +00:00
|
|
|
return true;
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2010-11-21 13:01:39 +00:00
|
|
|
|
2013-03-11 15:16:05 +00:00
|
|
|
bool GlxBackend::initFbConfig()
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2013-03-11 15:27:24 +00:00
|
|
|
const int attribs[] = {
|
2013-03-21 11:40:49 +00:00
|
|
|
GLX_RENDER_TYPE, GLX_RGBA_BIT,
|
2014-02-21 16:42:40 +00:00
|
|
|
GLX_DRAWABLE_TYPE, GLX_WINDOW_BIT,
|
2013-03-11 15:16:05 +00:00
|
|
|
GLX_RED_SIZE, 1,
|
|
|
|
GLX_GREEN_SIZE, 1,
|
|
|
|
GLX_BLUE_SIZE, 1,
|
|
|
|
GLX_ALPHA_SIZE, 0,
|
|
|
|
GLX_DEPTH_SIZE, 0,
|
|
|
|
GLX_STENCIL_SIZE, 0,
|
|
|
|
GLX_CONFIG_CAVEAT, GLX_NONE,
|
|
|
|
GLX_DOUBLEBUFFER, true,
|
|
|
|
0
|
|
|
|
};
|
|
|
|
|
2019-06-18 18:28:04 +00:00
|
|
|
const int attribs_srgb[] = {
|
|
|
|
GLX_RENDER_TYPE, GLX_RGBA_BIT,
|
|
|
|
GLX_DRAWABLE_TYPE, GLX_WINDOW_BIT,
|
|
|
|
GLX_RED_SIZE, 1,
|
|
|
|
GLX_GREEN_SIZE, 1,
|
|
|
|
GLX_BLUE_SIZE, 1,
|
|
|
|
GLX_ALPHA_SIZE, 0,
|
|
|
|
GLX_DEPTH_SIZE, 0,
|
|
|
|
GLX_STENCIL_SIZE, 0,
|
|
|
|
GLX_CONFIG_CAVEAT, GLX_NONE,
|
|
|
|
GLX_DOUBLEBUFFER, true,
|
|
|
|
GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB, true,
|
|
|
|
0
|
|
|
|
};
|
|
|
|
|
2019-10-15 14:06:30 +00:00
|
|
|
bool llvmpipe = false;
|
|
|
|
|
|
|
|
// Note that we cannot use GLPlatform::driver() here, because it has not been initialized at this point
|
|
|
|
if (hasExtension(QByteArrayLiteral("GLX_MESA_query_renderer"))) {
|
|
|
|
const QByteArray device = glXQueryRendererStringMESA(display(), DefaultScreen(display()), 0, GLX_RENDERER_DEVICE_ID_MESA);
|
|
|
|
if (device.contains(QByteArrayLiteral("llvmpipe"))) {
|
|
|
|
llvmpipe = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-06-18 18:28:04 +00:00
|
|
|
// Try to find a double buffered sRGB capable configuration
|
2013-03-11 15:16:05 +00:00
|
|
|
int count = 0;
|
2019-10-15 14:06:30 +00:00
|
|
|
GLXFBConfig *configs = nullptr;
|
|
|
|
|
|
|
|
// Don't request an sRGB configuration with LLVMpipe when the default depth is 16. See bug #408594.
|
|
|
|
if (!llvmpipe || Xcb::defaultDepth() > 16) {
|
|
|
|
configs = glXChooseFBConfig(display(), DefaultScreen(display()), attribs_srgb, &count);
|
|
|
|
}
|
2019-06-18 18:28:04 +00:00
|
|
|
|
|
|
|
if (count == 0) {
|
|
|
|
// Try to find a double buffered non-sRGB capable configuration
|
|
|
|
configs = glXChooseFBConfig(display(), DefaultScreen(display()), attribs, &count);
|
|
|
|
}
|
2012-10-30 17:20:00 +00:00
|
|
|
|
2014-12-08 21:45:13 +00:00
|
|
|
struct FBConfig {
|
|
|
|
GLXFBConfig config;
|
|
|
|
int depth;
|
|
|
|
int stencil;
|
|
|
|
};
|
|
|
|
|
|
|
|
std::deque<FBConfig> candidates;
|
|
|
|
|
|
|
|
for (int i = 0; i < count; i++) {
|
|
|
|
int depth, stencil;
|
|
|
|
glXGetFBConfigAttrib(display(), configs[i], GLX_DEPTH_SIZE, &depth);
|
|
|
|
glXGetFBConfigAttrib(display(), configs[i], GLX_STENCIL_SIZE, &stencil);
|
|
|
|
|
|
|
|
candidates.emplace_back(FBConfig{configs[i], depth, stencil});
|
|
|
|
}
|
|
|
|
|
|
|
|
if (count > 0)
|
2013-03-11 15:16:05 +00:00
|
|
|
XFree(configs);
|
2014-12-08 21:45:13 +00:00
|
|
|
|
|
|
|
std::stable_sort(candidates.begin(), candidates.end(), [](const FBConfig &left, const FBConfig &right) {
|
|
|
|
if (left.depth < right.depth)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (left.stencil < right.stencil)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
});
|
|
|
|
|
|
|
|
if (candidates.size() > 0) {
|
|
|
|
fbconfig = candidates.front().config;
|
2014-12-08 21:58:20 +00:00
|
|
|
|
2019-06-18 18:28:04 +00:00
|
|
|
int fbconfig_id, visual_id, red, green, blue, alpha, depth, stencil, srgb;
|
2014-12-08 21:58:20 +00:00
|
|
|
glXGetFBConfigAttrib(display(), fbconfig, GLX_FBCONFIG_ID, &fbconfig_id);
|
|
|
|
glXGetFBConfigAttrib(display(), fbconfig, GLX_VISUAL_ID, &visual_id);
|
|
|
|
glXGetFBConfigAttrib(display(), fbconfig, GLX_RED_SIZE, &red);
|
|
|
|
glXGetFBConfigAttrib(display(), fbconfig, GLX_GREEN_SIZE, &green);
|
|
|
|
glXGetFBConfigAttrib(display(), fbconfig, GLX_BLUE_SIZE, &blue);
|
|
|
|
glXGetFBConfigAttrib(display(), fbconfig, GLX_ALPHA_SIZE, &alpha);
|
|
|
|
glXGetFBConfigAttrib(display(), fbconfig, GLX_DEPTH_SIZE, &depth);
|
|
|
|
glXGetFBConfigAttrib(display(), fbconfig, GLX_STENCIL_SIZE, &stencil);
|
2019-06-18 18:28:04 +00:00
|
|
|
glXGetFBConfigAttrib(display(), fbconfig, GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB, &srgb);
|
2014-12-08 21:58:20 +00:00
|
|
|
|
2019-06-18 18:28:04 +00:00
|
|
|
qCDebug(KWIN_X11STANDALONE, "Choosing GLXFBConfig %#x X visual %#x depth %d RGBA %d:%d:%d:%d ZS %d:%d sRGB: %d",
|
|
|
|
fbconfig_id, visual_id, visualDepth(visual_id), red, green, blue, alpha, depth, stencil, srgb);
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2013-03-11 15:16:05 +00:00
|
|
|
|
2014-12-08 21:45:13 +00:00
|
|
|
if (fbconfig == nullptr) {
|
2016-04-12 13:03:07 +00:00
|
|
|
qCCritical(KWIN_X11STANDALONE) << "Failed to find a usable framebuffer configuration";
|
2010-11-21 13:01:39 +00:00
|
|
|
return false;
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2013-03-11 15:16:05 +00:00
|
|
|
|
2011-01-30 14:34:42 +00:00
|
|
|
return true;
|
|
|
|
}
|
2010-11-21 13:01:39 +00:00
|
|
|
|
2014-09-03 16:43:45 +00:00
|
|
|
void GlxBackend::initVisualDepthHashTable()
|
|
|
|
{
|
|
|
|
const xcb_setup_t *setup = xcb_get_setup(connection());
|
|
|
|
|
|
|
|
for (auto screen = xcb_setup_roots_iterator(setup); screen.rem; xcb_screen_next(&screen)) {
|
|
|
|
for (auto depth = xcb_screen_allowed_depths_iterator(screen.data); depth.rem; xcb_depth_next(&depth)) {
|
|
|
|
const int len = xcb_depth_visuals_length(depth.data);
|
|
|
|
const xcb_visualtype_t *visuals = xcb_depth_visuals(depth.data);
|
|
|
|
|
|
|
|
for (int i = 0; i < len; i++)
|
|
|
|
m_visualDepthHash.insert(visuals[i].visual_id, depth.data->depth);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
int GlxBackend::visualDepth(xcb_visualid_t visual) const
|
|
|
|
{
|
|
|
|
return m_visualDepthHash.value(visual);
|
|
|
|
}
|
|
|
|
|
2017-07-19 04:54:22 +00:00
|
|
|
static inline int bitCount(uint32_t mask)
|
|
|
|
{
|
|
|
|
#if defined(__GNUC__)
|
|
|
|
return __builtin_popcount(mask);
|
|
|
|
#else
|
|
|
|
int count = 0;
|
|
|
|
|
|
|
|
while (mask) {
|
|
|
|
count += (mask & 1);
|
|
|
|
mask >>= 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return count;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2014-04-13 18:47:58 +00:00
|
|
|
FBConfigInfo *GlxBackend::infoForVisual(xcb_visualid_t visual)
|
|
|
|
{
|
Reintroduce the useage of FBConfigInfo* hash in glxbackend
The hash was completely useless as we never inserted created
FBConfigInfo* into the hash. This change fixes the usage of the
hash and also ensures that it doesn't leak by deleting all hash
elements on tear down.
Current memleak backtrace from ASAN:
Direct leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x4dc932 in operator new(unsigned long) (/home/kfunk/devel/install/kf5/bin/kwin_x11+0x4dc932)
#1 0x7f3c596de0f3 in KWin::GlxBackend::infoForVisual(unsigned int) /home/kfunk/devel/src/kf5/kwin/glxbackend.cpp:454:12
#2 0x7f3c596e7ef4 in KWin::GlxTexture::loadTexture(unsigned int, QSize const&, unsigned int) /home/kfunk/devel/src/kf5/kwin/glxbackend.cpp:826:32
#3 0x7f3c596e921e in KWin::GlxTexture::loadTexture(KWin::WindowPixmap*) /home/kfunk/devel/src/kf5/kwin/glxbackend.cpp:869:12
#4 0x7f3c5916e895 in KWin::SceneOpenGL::Texture::load(KWin::WindowPixmap*) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1232:12
#5 0x7f3c5917019a in KWin::OpenGLWindowPixmap::bind() /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1681:20
#6 0x7f3c5916fce0 in KWin::SceneOpenGL::Window::bindTexture() /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1288:12
#7 0x7f3c5917294b in KWin::SceneOpenGL::Window::beginRenderWindow(int, QRegion const&, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1349:10
#8 0x7f3c59176f24 in KWin::SceneOpenGL2Window::performPaint(int, QRegion, KWin::WindowPaintData) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1510:10
#9 0x7f3c5916d410 in KWin::SceneOpenGL2::performPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1161:9
#10 0x7f3c5916cbc9 in KWin::SceneOpenGL2::finalDrawWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1147:9
#11 0x7f3c5922e92f in KWin::EffectsHandlerImpl::drawWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/effects.cpp:502:9
#12 0x7f3c590d7bc5 in KWin::Scene::finalPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene.cpp:606:5
#13 0x7f3c5922c979 in KWin::EffectsHandlerImpl::paintWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/effects.cpp:465:9
#14 0x7f3c590d2b38 in KWin::Scene::paintWindow(KWin::Scene::Window*, int, QRegion, KWin::WindowQuadList) /home/kfunk/devel/src/kf5/kwin/scene.cpp:478:5
#15 0x7f3c590ced89 in KWin::Scene::paintSimpleScreen(int, QRegion) /home/kfunk/devel/src/kf5/kwin/scene.cpp:381:9
#16 0x7f3c5916b2b1 in KWin::SceneOpenGL2::paintSimpleScreen(int, QRegion) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1098:12
#17 0x7f3c590c8bd3 in KWin::Scene::finalPaintScreen(int, QRegion, KWin::ScreenPaintData&) /home/kfunk/devel/src/kf5/kwin/scene.cpp:200:9
#18 0x7f3c5922b062 in KWin::EffectsHandlerImpl::paintScreen(int, QRegion, KWin::ScreenPaintData&) /home/kfunk/devel/src/kf5/kwin/effects.cpp:422:9
#19 0x7f3c590c791f in KWin::Scene::paintScreen(int*, QRegion const&, QRegion const&, QRegion*, QRegion*, QMatrix4x4 const&) /home/kfunk/devel/src/kf5/kwin/scene.cpp:150:5
#20 0x7f3c5915e500 in KWin::SceneOpenGL::paint(QRegion, QList<KWin::Toplevel*>) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:751:9
#21 0x7f3c5907ea3c in KWin::Compositor::performCompositing() /home/kfunk/devel/src/kf5/kwin/composite.cpp:726:29
#22 0x7f3c5907c230 in KWin::Compositor::startupWithWorkspace() /home/kfunk/devel/src/kf5/kwin/composite.cpp:347:5
#23 0x7f3c59079bbb in KWin::Compositor::slotCompositingOptionsInitialized() /home/kfunk/devel/src/kf5/kwin/composite.cpp:283:9
#24 0x7f3c59076084 in KWin::Compositor::setup() /home/kfunk/devel/src/kf5/kwin/composite.cpp:184:9
#25 0x7f3c598b165f in KWin::Compositor::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) /home/kfunk/devel/build/kf5/kwin/moc_composite.cpp:263:18
#26 0x7f3c52de67b0 in QObject::event(QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x2b67b0)
#27 0x7f3c536ab9db in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x15b9db)
REVIEW: 127096
2016-02-17 07:49:02 +00:00
|
|
|
auto it = m_fbconfigHash.constFind(visual);
|
|
|
|
if (it != m_fbconfigHash.constEnd()) {
|
|
|
|
return it.value();
|
|
|
|
}
|
2014-04-13 18:47:58 +00:00
|
|
|
|
Reintroduce the useage of FBConfigInfo* hash in glxbackend
The hash was completely useless as we never inserted created
FBConfigInfo* into the hash. This change fixes the usage of the
hash and also ensures that it doesn't leak by deleting all hash
elements on tear down.
Current memleak backtrace from ASAN:
Direct leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x4dc932 in operator new(unsigned long) (/home/kfunk/devel/install/kf5/bin/kwin_x11+0x4dc932)
#1 0x7f3c596de0f3 in KWin::GlxBackend::infoForVisual(unsigned int) /home/kfunk/devel/src/kf5/kwin/glxbackend.cpp:454:12
#2 0x7f3c596e7ef4 in KWin::GlxTexture::loadTexture(unsigned int, QSize const&, unsigned int) /home/kfunk/devel/src/kf5/kwin/glxbackend.cpp:826:32
#3 0x7f3c596e921e in KWin::GlxTexture::loadTexture(KWin::WindowPixmap*) /home/kfunk/devel/src/kf5/kwin/glxbackend.cpp:869:12
#4 0x7f3c5916e895 in KWin::SceneOpenGL::Texture::load(KWin::WindowPixmap*) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1232:12
#5 0x7f3c5917019a in KWin::OpenGLWindowPixmap::bind() /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1681:20
#6 0x7f3c5916fce0 in KWin::SceneOpenGL::Window::bindTexture() /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1288:12
#7 0x7f3c5917294b in KWin::SceneOpenGL::Window::beginRenderWindow(int, QRegion const&, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1349:10
#8 0x7f3c59176f24 in KWin::SceneOpenGL2Window::performPaint(int, QRegion, KWin::WindowPaintData) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1510:10
#9 0x7f3c5916d410 in KWin::SceneOpenGL2::performPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1161:9
#10 0x7f3c5916cbc9 in KWin::SceneOpenGL2::finalDrawWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1147:9
#11 0x7f3c5922e92f in KWin::EffectsHandlerImpl::drawWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/effects.cpp:502:9
#12 0x7f3c590d7bc5 in KWin::Scene::finalPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene.cpp:606:5
#13 0x7f3c5922c979 in KWin::EffectsHandlerImpl::paintWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/effects.cpp:465:9
#14 0x7f3c590d2b38 in KWin::Scene::paintWindow(KWin::Scene::Window*, int, QRegion, KWin::WindowQuadList) /home/kfunk/devel/src/kf5/kwin/scene.cpp:478:5
#15 0x7f3c590ced89 in KWin::Scene::paintSimpleScreen(int, QRegion) /home/kfunk/devel/src/kf5/kwin/scene.cpp:381:9
#16 0x7f3c5916b2b1 in KWin::SceneOpenGL2::paintSimpleScreen(int, QRegion) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1098:12
#17 0x7f3c590c8bd3 in KWin::Scene::finalPaintScreen(int, QRegion, KWin::ScreenPaintData&) /home/kfunk/devel/src/kf5/kwin/scene.cpp:200:9
#18 0x7f3c5922b062 in KWin::EffectsHandlerImpl::paintScreen(int, QRegion, KWin::ScreenPaintData&) /home/kfunk/devel/src/kf5/kwin/effects.cpp:422:9
#19 0x7f3c590c791f in KWin::Scene::paintScreen(int*, QRegion const&, QRegion const&, QRegion*, QRegion*, QMatrix4x4 const&) /home/kfunk/devel/src/kf5/kwin/scene.cpp:150:5
#20 0x7f3c5915e500 in KWin::SceneOpenGL::paint(QRegion, QList<KWin::Toplevel*>) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:751:9
#21 0x7f3c5907ea3c in KWin::Compositor::performCompositing() /home/kfunk/devel/src/kf5/kwin/composite.cpp:726:29
#22 0x7f3c5907c230 in KWin::Compositor::startupWithWorkspace() /home/kfunk/devel/src/kf5/kwin/composite.cpp:347:5
#23 0x7f3c59079bbb in KWin::Compositor::slotCompositingOptionsInitialized() /home/kfunk/devel/src/kf5/kwin/composite.cpp:283:9
#24 0x7f3c59076084 in KWin::Compositor::setup() /home/kfunk/devel/src/kf5/kwin/composite.cpp:184:9
#25 0x7f3c598b165f in KWin::Compositor::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) /home/kfunk/devel/build/kf5/kwin/moc_composite.cpp:263:18
#26 0x7f3c52de67b0 in QObject::event(QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x2b67b0)
#27 0x7f3c536ab9db in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x15b9db)
REVIEW: 127096
2016-02-17 07:49:02 +00:00
|
|
|
FBConfigInfo *info = new FBConfigInfo;
|
|
|
|
m_fbconfigHash.insert(visual, info);
|
2014-04-13 18:47:58 +00:00
|
|
|
info->fbconfig = nullptr;
|
|
|
|
info->bind_texture_format = 0;
|
|
|
|
info->texture_targets = 0;
|
|
|
|
info->y_inverted = 0;
|
|
|
|
info->mipmap = 0;
|
|
|
|
|
|
|
|
const xcb_render_pictformat_t format = XRenderUtils::findPictFormat(visual);
|
|
|
|
const xcb_render_directformat_t *direct = XRenderUtils::findPictFormatInfo(format);
|
|
|
|
|
|
|
|
if (!direct) {
|
2020-04-24 06:43:46 +00:00
|
|
|
qCCritical(KWIN_X11STANDALONE).nospace() << "Could not find a picture format for visual 0x" << Qt::hex << visual;
|
2014-04-13 18:47:58 +00:00
|
|
|
return info;
|
|
|
|
}
|
|
|
|
|
|
|
|
const int red_bits = bitCount(direct->red_mask);
|
|
|
|
const int green_bits = bitCount(direct->green_mask);
|
|
|
|
const int blue_bits = bitCount(direct->blue_mask);
|
|
|
|
const int alpha_bits = bitCount(direct->alpha_mask);
|
|
|
|
|
2014-09-03 16:43:45 +00:00
|
|
|
const int depth = visualDepth(visual);
|
|
|
|
|
2014-04-13 18:47:58 +00:00
|
|
|
const auto rgb_sizes = std::tie(red_bits, green_bits, blue_bits);
|
|
|
|
|
|
|
|
const int attribs[] = {
|
|
|
|
GLX_RENDER_TYPE, GLX_RGBA_BIT,
|
|
|
|
GLX_DRAWABLE_TYPE, GLX_WINDOW_BIT | GLX_PIXMAP_BIT,
|
|
|
|
GLX_X_VISUAL_TYPE, GLX_TRUE_COLOR,
|
|
|
|
GLX_X_RENDERABLE, True,
|
|
|
|
GLX_CONFIG_CAVEAT, int(GLX_DONT_CARE), // The ARGB32 visual is marked non-conformant in Catalyst
|
2017-11-20 16:35:23 +00:00
|
|
|
GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT, int(GLX_DONT_CARE), // The ARGB32 visual is marked sRGB capable in mesa/i965
|
2014-04-13 18:47:58 +00:00
|
|
|
GLX_BUFFER_SIZE, red_bits + green_bits + blue_bits + alpha_bits,
|
|
|
|
GLX_RED_SIZE, red_bits,
|
|
|
|
GLX_GREEN_SIZE, green_bits,
|
|
|
|
GLX_BLUE_SIZE, blue_bits,
|
|
|
|
GLX_ALPHA_SIZE, alpha_bits,
|
|
|
|
GLX_STENCIL_SIZE, 0,
|
|
|
|
GLX_DEPTH_SIZE, 0,
|
|
|
|
0
|
|
|
|
};
|
|
|
|
|
|
|
|
int count = 0;
|
|
|
|
GLXFBConfig *configs = glXChooseFBConfig(display(), DefaultScreen(display()), attribs, &count);
|
|
|
|
|
|
|
|
if (count < 1) {
|
2020-04-24 06:43:46 +00:00
|
|
|
qCCritical(KWIN_X11STANDALONE).nospace() << "Could not find a framebuffer configuration for visual 0x" << Qt::hex << visual;
|
2014-04-13 18:47:58 +00:00
|
|
|
return info;
|
|
|
|
}
|
|
|
|
|
2014-12-08 21:45:13 +00:00
|
|
|
struct FBConfig {
|
|
|
|
GLXFBConfig config;
|
|
|
|
int depth;
|
|
|
|
int stencil;
|
|
|
|
int format;
|
|
|
|
};
|
|
|
|
|
|
|
|
std::deque<FBConfig> candidates;
|
|
|
|
|
2014-04-13 18:47:58 +00:00
|
|
|
for (int i = 0; i < count; i++) {
|
|
|
|
int red, green, blue;
|
|
|
|
glXGetFBConfigAttrib(display(), configs[i], GLX_RED_SIZE, &red);
|
|
|
|
glXGetFBConfigAttrib(display(), configs[i], GLX_GREEN_SIZE, &green);
|
|
|
|
glXGetFBConfigAttrib(display(), configs[i], GLX_BLUE_SIZE, &blue);
|
|
|
|
|
|
|
|
if (std::tie(red, green, blue) != rgb_sizes)
|
|
|
|
continue;
|
|
|
|
|
2014-09-03 16:43:45 +00:00
|
|
|
xcb_visualid_t visual;
|
|
|
|
glXGetFBConfigAttrib(display(), configs[i], GLX_VISUAL_ID, (int *) &visual);
|
|
|
|
|
|
|
|
if (visualDepth(visual) != depth)
|
|
|
|
continue;
|
|
|
|
|
2014-04-13 18:47:58 +00:00
|
|
|
int bind_rgb, bind_rgba;
|
|
|
|
glXGetFBConfigAttrib(display(), configs[i], GLX_BIND_TO_TEXTURE_RGBA_EXT, &bind_rgba);
|
|
|
|
glXGetFBConfigAttrib(display(), configs[i], GLX_BIND_TO_TEXTURE_RGB_EXT, &bind_rgb);
|
|
|
|
|
|
|
|
if (!bind_rgb && !bind_rgba)
|
|
|
|
continue;
|
|
|
|
|
2014-12-08 21:45:13 +00:00
|
|
|
int depth, stencil;
|
|
|
|
glXGetFBConfigAttrib(display(), configs[i], GLX_DEPTH_SIZE, &depth);
|
|
|
|
glXGetFBConfigAttrib(display(), configs[i], GLX_STENCIL_SIZE, &stencil);
|
|
|
|
|
2014-04-13 18:47:58 +00:00
|
|
|
int texture_format;
|
|
|
|
if (alpha_bits)
|
|
|
|
texture_format = bind_rgba ? GLX_TEXTURE_FORMAT_RGBA_EXT : GLX_TEXTURE_FORMAT_RGB_EXT;
|
|
|
|
else
|
|
|
|
texture_format = bind_rgb ? GLX_TEXTURE_FORMAT_RGB_EXT : GLX_TEXTURE_FORMAT_RGBA_EXT;
|
|
|
|
|
2014-12-08 21:45:13 +00:00
|
|
|
candidates.emplace_back(FBConfig{configs[i], depth, stencil, texture_format});
|
|
|
|
}
|
|
|
|
|
|
|
|
if (count > 0)
|
|
|
|
XFree(configs);
|
|
|
|
|
|
|
|
std::stable_sort(candidates.begin(), candidates.end(), [](const FBConfig &left, const FBConfig &right) {
|
|
|
|
if (left.depth < right.depth)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (left.stencil < right.stencil)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
});
|
|
|
|
|
|
|
|
if (candidates.size() > 0) {
|
|
|
|
const FBConfig &candidate = candidates.front();
|
|
|
|
|
2014-04-13 18:47:58 +00:00
|
|
|
int y_inverted, texture_targets;
|
2014-12-08 21:45:13 +00:00
|
|
|
glXGetFBConfigAttrib(display(), candidate.config, GLX_BIND_TO_TEXTURE_TARGETS_EXT, &texture_targets);
|
|
|
|
glXGetFBConfigAttrib(display(), candidate.config, GLX_Y_INVERTED_EXT, &y_inverted);
|
2014-04-13 18:47:58 +00:00
|
|
|
|
2014-12-08 21:45:13 +00:00
|
|
|
info->fbconfig = candidate.config;
|
|
|
|
info->bind_texture_format = candidate.format;
|
2014-04-13 18:47:58 +00:00
|
|
|
info->texture_targets = texture_targets;
|
|
|
|
info->y_inverted = y_inverted;
|
|
|
|
info->mipmap = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (info->fbconfig) {
|
|
|
|
int fbc_id = 0;
|
|
|
|
int visual_id = 0;
|
|
|
|
|
|
|
|
glXGetFBConfigAttrib(display(), info->fbconfig, GLX_FBCONFIG_ID, &fbc_id);
|
|
|
|
glXGetFBConfigAttrib(display(), info->fbconfig, GLX_VISUAL_ID, &visual_id);
|
|
|
|
|
2020-04-24 06:43:46 +00:00
|
|
|
qCDebug(KWIN_X11STANDALONE).nospace() << "Using FBConfig 0x" << Qt::hex << fbc_id << " for visual 0x" << Qt::hex << visual_id;
|
2014-04-13 18:47:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return info;
|
|
|
|
}
|
|
|
|
|
2020-01-09 17:18:22 +00:00
|
|
|
void GlxBackend::setSwapInterval(int interval)
|
|
|
|
{
|
|
|
|
if (m_haveEXTSwapControl)
|
|
|
|
glXSwapIntervalEXT(display(), glxWindow, interval);
|
|
|
|
else if (m_haveMESASwapControl)
|
|
|
|
glXSwapIntervalMESA(interval);
|
2020-01-09 17:18:25 +00:00
|
|
|
else if (m_haveSGISwapControl)
|
|
|
|
glXSwapIntervalSGI(interval);
|
|
|
|
}
|
|
|
|
|
2020-11-18 13:14:36 +00:00
|
|
|
void GlxBackend::present(const QRegion &damage)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2014-11-25 07:40:23 +00:00
|
|
|
const QSize &screenSize = screens()->size();
|
|
|
|
const QRegion displayRegion(0, 0, screenSize.width(), screenSize.height());
|
2020-11-18 13:14:36 +00:00
|
|
|
const bool fullRepaint = supportsBufferAge() || (damage == displayRegion);
|
2013-03-11 15:27:24 +00:00
|
|
|
|
2020-01-09 17:05:36 +00:00
|
|
|
if (fullRepaint) {
|
2020-11-18 13:49:25 +00:00
|
|
|
glXSwapBuffers(display(), glxWindow);
|
2014-01-24 21:29:30 +00:00
|
|
|
if (supportsBufferAge()) {
|
|
|
|
glXQueryDrawable(display(), glxWindow, GLX_BACK_BUFFER_AGE_EXT, (GLuint *) &m_bufferAge);
|
|
|
|
}
|
2014-02-11 18:57:06 +00:00
|
|
|
} else if (m_haveMESACopySubBuffer) {
|
2020-11-18 13:14:36 +00:00
|
|
|
for (const QRect &r : damage) {
|
2013-03-11 15:27:24 +00:00
|
|
|
// convert to OpenGL coordinates
|
2014-11-25 07:40:23 +00:00
|
|
|
int y = screenSize.height() - r.y() - r.height();
|
2014-02-11 18:57:06 +00:00
|
|
|
glXCopySubBufferMESA(display(), glxWindow, r.x(), y, r.width(), r.height());
|
2013-03-11 15:27:24 +00:00
|
|
|
}
|
2020-01-09 17:05:36 +00:00
|
|
|
} else { // Copy Pixels (horribly slow on Mesa)
|
2013-03-11 15:27:24 +00:00
|
|
|
glDrawBuffer(GL_FRONT);
|
2020-11-18 13:14:36 +00:00
|
|
|
copyPixels(damage);
|
2013-03-11 15:27:24 +00:00
|
|
|
glDrawBuffer(GL_BACK);
|
2010-11-21 13:01:39 +00:00
|
|
|
}
|
2013-03-26 20:49:59 +00:00
|
|
|
|
2014-01-24 21:29:30 +00:00
|
|
|
if (!supportsBufferAge()) {
|
|
|
|
glXWaitGL();
|
|
|
|
XFlush(display());
|
|
|
|
}
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2010-11-21 13:01:39 +00:00
|
|
|
|
2012-08-26 15:14:23 +00:00
|
|
|
void GlxBackend::screenGeometryChanged(const QSize &size)
|
2011-11-26 15:15:46 +00:00
|
|
|
{
|
Better handling for making the compositing OpenGL context current
With QtQuick2 it's possible that the scene graph rendering context either
lives in an own thread or uses the main GUI thread. In the latter case
it's the same thread as our compositing OpenGL context lives in. This
means our basic assumption that between two rendering passes the context
stays current does not hold.
The code already ensured that before we start a rendering pass the
context is made current, but there are many more possible cases. If we
use OpenGL in areas not triggered by the rendering loop but in response
to other events the context needs to be made current. This includes the
loading and unloading of effects (some effects use OpenGL in the static
effect check, in the ctor and dtor), background loading of texture data,
lazy loading after first usage invoked by shortcut, etc. etc.
To properly handle these cases new methods are added to EffectsHandler
to make the compositing OpenGL context current. These calls delegate down
into the scene. On non-OpenGL scenes they are noop, but on OpenGL they go
into the backend and make the context current. In addition they ensure
that Qt doesn't think that it's QOpenGLContext is current by calling
doneCurrent() on the QOpenGLContext::currentContext(). This unfortunately
causes an additional call to makeCurrent with a null context, but there
is no other way to tell Qt - it doesn't notice when a different context
is made current with low level API calls. In the multi-threaded
architecture this doesn't matter as ::currentContext() returns null.
A short evaluation showed that a transition to QOpenGLContext doesn't
seem feasible. Qt only supports either GLX or EGL while KWin supports
both and when entering the transition phase for Wayland, it would become
extremely tricky if our native platform is X11, but we want a Wayland
EGL context. A future solution might be to have a "KWin-QPA plugin" which
uses either xcb or Wayland and hides everything from Qt.
The API documentation is extended to describe when the effects-framework
ensures that an OpenGL context is current. The effects are changed to
make the context current in cases where it's not guaranteed. This has
been done by looking for creation or deletion of GLTextures and Shaders.
If there are other OpenGL usages outside the rendering loop, ctor/dtor
this needs to be changed, too.
2013-11-22 14:05:36 +00:00
|
|
|
doneCurrent();
|
2013-03-11 15:27:24 +00:00
|
|
|
|
|
|
|
XMoveResizeWindow(display(), window, 0, 0, size.width(), size.height());
|
|
|
|
overlayWindow()->setup(window);
|
2013-09-10 09:03:28 +00:00
|
|
|
Xcb::sync();
|
2013-03-11 15:27:24 +00:00
|
|
|
|
Better handling for making the compositing OpenGL context current
With QtQuick2 it's possible that the scene graph rendering context either
lives in an own thread or uses the main GUI thread. In the latter case
it's the same thread as our compositing OpenGL context lives in. This
means our basic assumption that between two rendering passes the context
stays current does not hold.
The code already ensured that before we start a rendering pass the
context is made current, but there are many more possible cases. If we
use OpenGL in areas not triggered by the rendering loop but in response
to other events the context needs to be made current. This includes the
loading and unloading of effects (some effects use OpenGL in the static
effect check, in the ctor and dtor), background loading of texture data,
lazy loading after first usage invoked by shortcut, etc. etc.
To properly handle these cases new methods are added to EffectsHandler
to make the compositing OpenGL context current. These calls delegate down
into the scene. On non-OpenGL scenes they are noop, but on OpenGL they go
into the backend and make the context current. In addition they ensure
that Qt doesn't think that it's QOpenGLContext is current by calling
doneCurrent() on the QOpenGLContext::currentContext(). This unfortunately
causes an additional call to makeCurrent with a null context, but there
is no other way to tell Qt - it doesn't notice when a different context
is made current with low level API calls. In the multi-threaded
architecture this doesn't matter as ::currentContext() returns null.
A short evaluation showed that a transition to QOpenGLContext doesn't
seem feasible. Qt only supports either GLX or EGL while KWin supports
both and when entering the transition phase for Wayland, it would become
extremely tricky if our native platform is X11, but we want a Wayland
EGL context. A future solution might be to have a "KWin-QPA plugin" which
uses either xcb or Wayland and hides everything from Qt.
The API documentation is extended to describe when the effects-framework
ensures that an OpenGL context is current. The effects are changed to
make the context current in cases where it's not guaranteed. This has
been done by looking for creation or deletion of GLTextures and Shaders.
If there are other OpenGL usages outside the rendering loop, ctor/dtor
this needs to be changed, too.
2013-11-22 14:05:36 +00:00
|
|
|
makeCurrent();
|
2013-03-11 15:27:24 +00:00
|
|
|
glViewport(0, 0, size.width(), size.height());
|
2013-11-21 09:44:06 +00:00
|
|
|
|
|
|
|
// The back buffer contents are now undefined
|
|
|
|
m_bufferAge = 0;
|
2011-11-26 15:15:46 +00:00
|
|
|
}
|
|
|
|
|
2017-09-08 20:30:18 +00:00
|
|
|
SceneOpenGLTexturePrivate *GlxBackend::createBackendTexture(SceneOpenGLTexture *texture)
|
2012-08-26 15:14:23 +00:00
|
|
|
{
|
|
|
|
return new GlxTexture(texture, this);
|
|
|
|
}
|
2010-11-21 13:01:39 +00:00
|
|
|
|
2020-11-09 14:31:26 +00:00
|
|
|
QRegion GlxBackend::beginFrame(int screenId)
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2020-11-09 14:23:41 +00:00
|
|
|
Q_UNUSED(screenId)
|
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-11-21 09:44:06 +00:00
|
|
|
QRegion repaint;
|
2020-11-09 14:23:41 +00:00
|
|
|
makeCurrent();
|
2020-01-09 17:06:14 +00:00
|
|
|
|
2013-11-21 09:44:06 +00:00
|
|
|
if (supportsBufferAge())
|
|
|
|
repaint = accumulatedDamageHistory(m_bufferAge);
|
|
|
|
|
2020-01-09 17:06:14 +00:00
|
|
|
glXWaitX();
|
2013-11-21 09:39:29 +00:00
|
|
|
|
2013-11-21 09:44:06 +00:00
|
|
|
return repaint;
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2010-11-21 13:01:39 +00:00
|
|
|
|
2020-11-09 14:31:26 +00:00
|
|
|
void GlxBackend::endFrame(int screenId, const QRegion &renderedRegion, const QRegion &damagedRegion)
|
2012-08-26 15:14:23 +00:00
|
|
|
{
|
2020-11-09 14:23:41 +00:00
|
|
|
Q_UNUSED(screenId)
|
|
|
|
|
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
|
|
|
// If the GLX_INTEL_swap_event extension is not used for getting presentation feedback,
|
|
|
|
// assume that the frame will be presented at the next vblank event, this is racy.
|
|
|
|
if (m_vsyncMonitor) {
|
|
|
|
m_vsyncMonitor->arm();
|
|
|
|
}
|
|
|
|
|
2020-11-18 13:14:36 +00:00
|
|
|
present(renderedRegion);
|
2012-08-26 15:14:23 +00:00
|
|
|
|
|
|
|
if (overlayWindow()->window()) // show the window only after the first pass,
|
|
|
|
overlayWindow()->show(); // since that pass may take long
|
2013-11-21 09:44:06 +00:00
|
|
|
|
|
|
|
// Save the damaged region to history
|
|
|
|
if (supportsBufferAge())
|
|
|
|
addToDamageHistory(damagedRegion);
|
2012-08-26 15:14: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 GlxBackend::vblank(std::chrono::nanoseconds timestamp)
|
|
|
|
{
|
|
|
|
RenderLoopPrivate *renderLoopPrivate = RenderLoopPrivate::get(m_backend->renderLoop());
|
|
|
|
renderLoopPrivate->notifyFrameCompleted(timestamp);
|
|
|
|
}
|
|
|
|
|
Better handling for making the compositing OpenGL context current
With QtQuick2 it's possible that the scene graph rendering context either
lives in an own thread or uses the main GUI thread. In the latter case
it's the same thread as our compositing OpenGL context lives in. This
means our basic assumption that between two rendering passes the context
stays current does not hold.
The code already ensured that before we start a rendering pass the
context is made current, but there are many more possible cases. If we
use OpenGL in areas not triggered by the rendering loop but in response
to other events the context needs to be made current. This includes the
loading and unloading of effects (some effects use OpenGL in the static
effect check, in the ctor and dtor), background loading of texture data,
lazy loading after first usage invoked by shortcut, etc. etc.
To properly handle these cases new methods are added to EffectsHandler
to make the compositing OpenGL context current. These calls delegate down
into the scene. On non-OpenGL scenes they are noop, but on OpenGL they go
into the backend and make the context current. In addition they ensure
that Qt doesn't think that it's QOpenGLContext is current by calling
doneCurrent() on the QOpenGLContext::currentContext(). This unfortunately
causes an additional call to makeCurrent with a null context, but there
is no other way to tell Qt - it doesn't notice when a different context
is made current with low level API calls. In the multi-threaded
architecture this doesn't matter as ::currentContext() returns null.
A short evaluation showed that a transition to QOpenGLContext doesn't
seem feasible. Qt only supports either GLX or EGL while KWin supports
both and when entering the transition phase for Wayland, it would become
extremely tricky if our native platform is X11, but we want a Wayland
EGL context. A future solution might be to have a "KWin-QPA plugin" which
uses either xcb or Wayland and hides everything from Qt.
The API documentation is extended to describe when the effects-framework
ensures that an OpenGL context is current. The effects are changed to
make the context current in cases where it's not guaranteed. This has
been done by looking for creation or deletion of GLTextures and Shaders.
If there are other OpenGL usages outside the rendering loop, ctor/dtor
this needs to be changed, too.
2013-11-22 14:05:36 +00:00
|
|
|
bool GlxBackend::makeCurrent()
|
|
|
|
{
|
|
|
|
if (QOpenGLContext *context = QOpenGLContext::currentContext()) {
|
|
|
|
// Workaround to tell Qt that no QOpenGLContext is current
|
|
|
|
context->doneCurrent();
|
|
|
|
}
|
|
|
|
const bool current = glXMakeCurrent(display(), glxWindow, ctx);
|
|
|
|
return current;
|
|
|
|
}
|
|
|
|
|
|
|
|
void GlxBackend::doneCurrent()
|
|
|
|
{
|
|
|
|
glXMakeCurrent(display(), None, nullptr);
|
|
|
|
}
|
2012-08-26 15:14:23 +00:00
|
|
|
|
2019-08-07 17:33:20 +00:00
|
|
|
OverlayWindow* GlxBackend::overlayWindow() const
|
2013-06-19 10:26:34 +00:00
|
|
|
{
|
|
|
|
return m_overlayWindow;
|
|
|
|
}
|
|
|
|
|
2012-08-26 15:14:23 +00:00
|
|
|
/********************************************************
|
|
|
|
* GlxTexture
|
|
|
|
*******************************************************/
|
2017-09-08 20:30:18 +00:00
|
|
|
GlxTexture::GlxTexture(SceneOpenGLTexture *texture, GlxBackend *backend)
|
|
|
|
: SceneOpenGLTexturePrivate()
|
2012-08-26 15:14:23 +00:00
|
|
|
, q(texture)
|
|
|
|
, m_backend(backend)
|
|
|
|
, m_glxpixmap(None)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
GlxTexture::~GlxTexture()
|
2011-07-18 15:55:39 +00:00
|
|
|
{
|
|
|
|
if (m_glxpixmap != None) {
|
2012-02-20 09:25:13 +00:00
|
|
|
if (!options->isGlStrictBinding()) {
|
2011-07-18 15:55:39 +00:00
|
|
|
glXReleaseTexImageEXT(display(), m_glxpixmap, GLX_FRONT_LEFT_EXT);
|
2011-02-05 10:55:10 +00:00
|
|
|
}
|
2011-07-18 15:55:39 +00:00
|
|
|
glXDestroyPixmap(display(), m_glxpixmap);
|
2011-08-25 08:29:23 +00:00
|
|
|
m_glxpixmap = None;
|
2010-11-21 13:01:39 +00:00
|
|
|
}
|
2011-01-30 14:34:42 +00:00
|
|
|
}
|
2010-11-21 13:01:39 +00:00
|
|
|
|
2012-08-26 15:14:23 +00:00
|
|
|
void GlxTexture::onDamage()
|
|
|
|
{
|
|
|
|
if (options->isGlStrictBinding() && m_glxpixmap) {
|
|
|
|
glXReleaseTexImageEXT(display(), m_glxpixmap, GLX_FRONT_LEFT_EXT);
|
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
|
|
|
glXBindTexImageEXT(display(), m_glxpixmap, GLX_FRONT_LEFT_EXT, nullptr);
|
2012-08-26 15:14:23 +00:00
|
|
|
}
|
|
|
|
GLTexturePrivate::onDamage();
|
|
|
|
}
|
|
|
|
|
2014-04-13 18:47:58 +00:00
|
|
|
bool GlxTexture::loadTexture(xcb_pixmap_t pixmap, const QSize &size, xcb_visualid_t visual)
|
|
|
|
{
|
|
|
|
if (pixmap == XCB_NONE || size.isEmpty() || visual == XCB_NONE)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
const FBConfigInfo *info = m_backend->infoForVisual(visual);
|
|
|
|
if (!info || info->fbconfig == nullptr)
|
|
|
|
return false;
|
|
|
|
|
2014-11-22 14:53:15 +00:00
|
|
|
if (info->texture_targets & GLX_TEXTURE_2D_BIT_EXT) {
|
2014-04-13 18:47:58 +00:00
|
|
|
m_target = GL_TEXTURE_2D;
|
|
|
|
m_scale.setWidth(1.0f / m_size.width());
|
|
|
|
m_scale.setHeight(1.0f / m_size.height());
|
|
|
|
} else {
|
2019-08-31 14:28:37 +00:00
|
|
|
Q_ASSERT(info->texture_targets & GLX_TEXTURE_RECTANGLE_BIT_EXT);
|
2014-04-13 18:47:58 +00:00
|
|
|
|
|
|
|
m_target = GL_TEXTURE_RECTANGLE;
|
|
|
|
m_scale.setWidth(1.0f);
|
|
|
|
m_scale.setHeight(1.0f);
|
|
|
|
}
|
|
|
|
|
|
|
|
const int attrs[] = {
|
|
|
|
GLX_TEXTURE_FORMAT_EXT, info->bind_texture_format,
|
2014-12-08 21:44:23 +00:00
|
|
|
GLX_MIPMAP_TEXTURE_EXT, false,
|
2014-04-13 18:47:58 +00:00
|
|
|
GLX_TEXTURE_TARGET_EXT, m_target == GL_TEXTURE_2D ? GLX_TEXTURE_2D_EXT : GLX_TEXTURE_RECTANGLE_EXT,
|
|
|
|
0
|
|
|
|
};
|
|
|
|
|
|
|
|
m_glxpixmap = glXCreatePixmap(display(), info->fbconfig, pixmap, attrs);
|
|
|
|
m_size = size;
|
|
|
|
m_yInverted = info->y_inverted ? true : false;
|
2014-12-08 21:44:23 +00:00
|
|
|
m_canUseMipmaps = false;
|
2014-04-13 18:47:58 +00:00
|
|
|
|
|
|
|
glGenTextures(1, &m_texture);
|
|
|
|
|
|
|
|
q->setDirty();
|
2014-12-08 21:44:23 +00:00
|
|
|
q->setFilter(GL_NEAREST);
|
2014-04-13 18:47:58 +00:00
|
|
|
|
|
|
|
glBindTexture(m_target, m_texture);
|
|
|
|
glXBindTexImageEXT(display(), m_glxpixmap, GLX_FRONT_LEFT_EXT, nullptr);
|
|
|
|
|
|
|
|
updateMatrix();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-02-11 10:00:12 +00:00
|
|
|
bool GlxTexture::loadTexture(WindowPixmap *pixmap)
|
|
|
|
{
|
|
|
|
Toplevel *t = pixmap->toplevel();
|
[x11] Add support for _GTK_FRAME_EXTENTS
Summary:
KDE is known for having a strong view on the client-side decorations vs
server-side decorations issue. The main argument raised against CSD is
that desktop will look less consistent when clients start drawing window
decorations by themselves, which is somewhat true. It all ties to how
well each toolkit is integrated with the desktop environment.
KDE doesn't control the desktop market on Linux. Another big "player"
is GNOME. Both KDE and GNOME have very polarized views on in which
direction desktop should move forward. The KDE community is pushing more
toward server-side decorations while the GNOME community is pushing
more toward client-side decorations. Both communities have developed
great applications and it's not rare to see a GNOME application being
used in KDE Plasma. The only problem is that these different views are
not left behind the curtain and our users pay the price. Resizing GTK
clients in Plasma became practically impossible due to resize borders
having small hit area.
When a client draws its window decoration, it's more likely that it also
draws the drop-shadow around the decoration. The compositor must know
the extents of the shadow so things like snapping and so on work as
expected. And here lies the problem... While the xdg-shell protocol has
a way to specify such things, the NetWM spec doesn't have anything like
that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with
it is that it's a proprietary atom, which is specific only to GTK apps.
Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing
anything like that would require major changes in how we think about
geometry.
Recent xdg-shell window geometry patches adjusted geometry abstractions
in kwin to such a degree that it's very easy to add support for client
side decorated clients on X11. We just have to make sure that the
X11Client class provides correct buffer geometry and frame geometry when
the gtk frame extents are set.
Even though the X11 code is feature frozen, I still think it's worth
to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize
issues. Also, because KWin/Wayland is unfortunately far from becoming
default, it will help us with testing some implementation bits of the
window geometry from xdg-shell.
BUG: 390550
FIXED-IN: 5.18.0
Test Plan:
Things like quick tiling, maximizing, tiling scripts and so on work as
expected with GTK clients.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: cblack, trmdi, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24660
2019-10-08 08:46:59 +00:00
|
|
|
return loadTexture(pixmap->pixmap(), t->bufferGeometry().size(), t->visual());
|
2015-02-11 10:00:12 +00:00
|
|
|
}
|
|
|
|
|
2012-08-26 15:14:23 +00:00
|
|
|
OpenGLBackend *GlxTexture::backend()
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2012-08-26 15:14:23 +00:00
|
|
|
return m_backend;
|
2012-01-07 11:12:29 +00:00
|
|
|
}
|
2012-08-26 15:14:23 +00:00
|
|
|
|
|
|
|
} // namespace
|