kwin/src/scene.h

439 lines
14 KiB
C
Raw Normal View History

2020-08-02 22:22:19 +00:00
/*
KWin - the KDE window manager
This file is part of the KDE project.
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 2006 Lubos Lunak <l.lunak@kde.org>
2020-08-02 22:22:19 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
#ifndef KWIN_SCENE_H
#define KWIN_SCENE_H
#include "toplevel.h"
#include "utils.h"
#include "kwineffects.h"
#include <QElapsedTimer>
#include <QMatrix4x4>
namespace KWin
{
namespace Decoration
{
class DecoratedClientImpl;
}
class AbstractOutput;
class AbstractThumbnailItem;
class DecorationRenderer;
class Deleted;
class EffectFrameImpl;
class EffectWindowImpl;
class GLTexture;
class Item;
class OverlayWindow;
class PlatformSurfaceTexture;
class RenderLoop;
class Shadow;
class ShadowItem;
class SurfaceItem;
class SurfacePixmapInternal;
class SurfacePixmapWayland;
class SurfacePixmapX11;
class WindowItem;
// The base class for compositing backends.
class KWIN_EXPORT Scene : public QObject
2011-01-30 14:34:42 +00:00
{
Q_OBJECT
2011-01-30 14:34:42 +00:00
public:
explicit Scene(QObject *parent = nullptr);
Run clang-tidy with modernize-use-override check Summary: Currently code base of kwin can be viewed as two pieces. One is very ancient, and the other one is more modern, which uses new C++ features. The main problem with the ancient code is that it was written before C++11 era. So, no override or final keywords, lambdas, etc. Quite recently, KDE compiler settings were changed to show a warning if a virtual method has missing override keyword. As you might have already guessed, this fired back at us because of that ancient code. We had about 500 new compiler warnings. A "solution" was proposed to that problem - disable -Wno-suggest-override and the other similar warning for clang. It's hard to call a solution because those warnings are disabled not only for the old code, but also for new. This is not what we want! The main argument for not actually fixing the problem was that git history will be screwed as well because of human factor. While good git history is a very important thing, we should not go crazy about it and block every change that somehow alters git history. git blame allows to specify starting revision for a reason. The other argument (human factor) can be easily solved by using tools such as clang-tidy. clang-tidy is a clang-based linter for C++. It can be used for various things, e.g. fixing coding style(e.g. add missing braces to if statements, readability-braces-around-statements check), or in our case add missing override keywords. Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, apol, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 16:52:26 +00:00
~Scene() override = 0;
2011-01-30 14:34:42 +00:00
class EffectFrame;
class Window;
/**
* Schedules a repaint for the specified @a region.
*/
void addRepaint(const QRegion &region);
/**
* Returns the repaints region for output with the specified @a screenId.
*/
QRegion repaints(int screenId) const;
void resetRepaints(int screenId);
2011-01-30 14:34:42 +00:00
// Returns true if the ctor failed to properly initialize.
virtual bool initFailed() const = 0;
virtual CompositingType compositingType() const = 0;
2011-01-30 14:34:42 +00:00
// Repaints the given screen areas, windows provides the stacking order.
// The entry point for the main part of the painting pass.
// returns the time since the last vblank signal - if there's one
// ie. "what of this frame is lost to painting"
Provide expected presentation time to effects Effects are given the interval between two consecutive frames. The main flaw of this approach is that if the Compositor transitions from the idle state to "active" state, i.e. when there is something to repaint, effects may see a very large interval between the last painted frame and the current. In order to address this issue, the Scene invalidates the timer that is used to measure time between consecutive frames before the Compositor is about to become idle. While this works perfectly fine with Xinerama-style rendering, with per screen rendering, determining whether the compositor is about to idle is rather a tedious task mostly because a single output can't be used for the test. Furthermore, since the Compositor schedules pointless repaints just to ensure that it's idle, it might take several attempts to figure out whether the scene timer must be invalidated if you use (true) per screen rendering. Ideally, all effects should use a timeline helper that is aware of the underlying render loop and its timings. However, this option is off the table because it will involve a lot of work to implement it. Alternative and much simpler option is to pass the expected presentation time to effects rather than time between consecutive frames. This means that effects are responsible for determining how much animation timelines have to be advanced. Typically, an effect would have to store the presentation timestamp provided in either prePaint{Screen,Window} and use it in the subsequent prePaint{Screen,Window} call to estimate the amount of time passed between the next and the last frames. Unfortunately, this is an API incompatible change. However, it shouldn't take a lot of work to port third-party binary effects, which don't use the AnimationEffect class, to the new API. On the bright side, we no longer need to be concerned about the Compositor getting idle. We do still try to determine whether the Compositor is about to idle, primarily, because the OpenGL render backend swaps buffers on present, but that will change with the ongoing compositing timing rework.
2020-11-20 15:44:04 +00:00
virtual void paint(int screenId, const QRegion &damage, const QList<Toplevel *> &windows,
RenderLoop *renderLoop) = 0;
2011-01-30 14:34:42 +00:00
/**
* Adds the Toplevel to the Scene.
*
* If the toplevel gets deleted, then the scene will try automatically
* to re-bind an underlying scene window to the corresponding Deleted.
*
* @param toplevel The window to be added.
* @note You can add a toplevel to scene only once.
*/
void addToplevel(Toplevel *toplevel);
/**
* Removes the Toplevel from the Scene.
*
* @param toplevel The window to be removed.
* @note You can remove a toplevel from the scene only once.
*/
void removeToplevel(Toplevel *toplevel);
2011-01-30 14:34:42 +00:00
/**
* @brief Creates the Scene backend of an EffectFrame.
*
* @param frame The EffectFrame this Scene::EffectFrame belongs to.
*/
virtual Scene::EffectFrame *createEffectFrame(EffectFrameImpl *frame) = 0;
/**
* @brief Creates the Scene specific Shadow subclass.
*
* An implementing class has to create a proper instance. It is not allowed to
* return @c null.
*
* @param toplevel The Toplevel for which the Shadow needs to be created.
*/
virtual Shadow *createShadow(Toplevel *toplevel) = 0;
/**
* Method invoked when the screen geometry is changed.
* Reimplementing classes should also invoke the parent method
* as it takes care of resizing the overlay window.
* @param size The new screen geometry size
*/
virtual void screenGeometryChanged(const QSize &size);
2011-01-30 14:34:42 +00:00
// Flags controlling how painting is done.
enum {
// Window (or at least part of it) will be painted opaque.
PAINT_WINDOW_OPAQUE = 1 << 0,
// Window (or at least part of it) will be painted translucent.
PAINT_WINDOW_TRANSLUCENT = 1 << 1,
// Window will be painted with transformed geometry.
PAINT_WINDOW_TRANSFORMED = 1 << 2,
// Paint only a region of the screen (can be optimized, cannot
// be used together with TRANSFORMED flags).
PAINT_SCREEN_REGION = 1 << 3,
// Whole screen will be painted with transformed geometry.
PAINT_SCREEN_TRANSFORMED = 1 << 4,
// At least one window will be painted with transformed geometry.
PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS = 1 << 5,
// Clear whole background as the very first step, without optimizing it
PAINT_SCREEN_BACKGROUND_FIRST = 1 << 6,
// PAINT_DECORATION_ONLY = 1 << 7 has been removed
2011-01-30 14:34:42 +00:00
// Window will be painted with a lanczos filter.
2012-03-02 13:03:05 +00:00
PAINT_WINDOW_LANCZOS = 1 << 8
// PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS_WITHOUT_FULL_REPAINTS = 1 << 9 has been removed
};
2011-01-30 14:34:42 +00:00
// types of filtering available
2021-03-14 17:06:22 +00:00
enum ImageFilterType {
ImageFilterFast,
ImageFilterGood,
};
virtual OverlayWindow* overlayWindow() const = 0;
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
virtual bool makeOpenGLContextCurrent();
virtual void doneOpenGLContextCurrent();
virtual bool supportsSurfacelessContext() const;
virtual bool supportsNativeFence() const;
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
virtual QMatrix4x4 screenProjectionMatrix() const;
virtual DecorationRenderer *createDecorationRenderer(Decoration::DecoratedClientImpl *) = 0;
/**
* Whether the Scene is able to drive animations.
* This is used as a hint to the effects system which effects can be supported.
* If the Scene performs software rendering it is supposed to return @c false,
* if rendering is hardware accelerated it should return @c true.
*/
virtual bool animationsSupported() const = 0;
/**
* The QPainter used by a QPainter based compositor scene.
* Default implementation returns @c nullptr;
*/
virtual QPainter *scenePainter() const;
/**
* The render buffer used by a QPainter based compositor.
* Default implementation returns @c nullptr.
*/
virtual QImage *qpainterRenderBuffer(int screenId) const;
/**
* The backend specific extensions (e.g. EGL/GLX extensions).
*
* Not the OpenGL (ES) extension!
*
* Default implementation returns empty list
*/
virtual QVector<QByteArray> openGLPlatformInterfaceExtensions() const;
virtual QSharedPointer<GLTexture> textureForOutput(AbstractOutput *output) const {
Q_UNUSED(output);
return {};
}
virtual PlatformSurfaceTexture *createPlatformSurfaceTextureInternal(SurfacePixmapInternal *pixmap);
virtual PlatformSurfaceTexture *createPlatformSurfaceTextureX11(SurfacePixmapX11 *pixmap);
virtual PlatformSurfaceTexture *createPlatformSurfaceTextureWayland(SurfacePixmapWayland *pixmap);
Q_SIGNALS:
void frameRendered();
void resetCompositing();
public Q_SLOTS:
// a window has been closed
void windowClosed(KWin::Toplevel* c, KWin::Deleted* deleted);
2011-01-30 14:34:42 +00:00
protected:
virtual Window *createWindow(Toplevel *toplevel) = 0;
void createStackingOrder(const QList<Toplevel *> &toplevels);
void clearStackingOrder();
2011-01-30 14:34:42 +00:00
// shared implementation, starts painting the screen
void paintScreen(int *mask, const QRegion &damage, const QRegion &repaint,
QRegion *updateRegion, QRegion *validRegion, RenderLoop *renderLoop,
const QMatrix4x4 &projection = QMatrix4x4());
// Render cursor texture in case hardware cursor is disabled/non-applicable
virtual void paintCursor(const QRegion &region) = 0;
2011-01-30 14:34:42 +00:00
friend class EffectsHandlerImpl;
// called after all effects had their paintScreen() called
void finalPaintScreen(int mask, const QRegion &region, ScreenPaintData& data);
2011-01-30 14:34:42 +00:00
// shared implementation of painting the screen in the generic
// (unoptimized) way
virtual void paintGenericScreen(int mask, const ScreenPaintData &data);
2011-01-30 14:34:42 +00:00
// shared implementation of painting the screen in an optimized way
virtual void paintSimpleScreen(int mask, const QRegion &region);
2011-01-30 14:34:42 +00:00
// paint the background (not the desktop background - the whole background)
virtual void paintBackground(const QRegion &region) = 0;
/**
* Notifies about starting to paint.
*
* @p damage contains the reported damage as suggested by windows and effects on prepaint calls.
*/
virtual void aboutToStartPainting(int screenId, const QRegion &damage);
2011-01-30 14:34:42 +00:00
// called after all effects had their paintWindow() called
void finalPaintWindow(EffectWindowImpl* w, int mask, const QRegion &region, WindowPaintData& data);
2011-01-30 14:34:42 +00:00
// shared implementation, starts painting the window
virtual void paintWindow(Window* w, int mask, const QRegion &region);
2011-01-30 14:34:42 +00:00
// called after all effects had their drawWindow() called
virtual void finalDrawWindow(EffectWindowImpl* w, int mask, const QRegion &region, WindowPaintData& data);
// let the scene decide whether it's better to paint more of the screen, eg. in order to allow a buffer swap
// the default is NOOP
virtual void extendPaintRegion(QRegion &region, bool opaqueFullscreen);
virtual void paintDesktop(int desktop, int mask, const QRegion &region, ScreenPaintData &data);
[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
virtual void paintEffectQuickView(EffectQuickView *w) = 0;
2011-01-30 14:34:42 +00:00
// saved data for 2nd pass of optimized screen painting
struct Phase2Data {
Window *window = nullptr;
2011-01-30 14:34:42 +00:00
QRegion region;
QRegion clip;
int mask = 0;
2011-01-30 14:34:42 +00:00
};
// The region which actually has been painted by paintScreen() and should be
// copied from the buffer to the screen. I.e. the region returned from Scene::paintScreen().
// Since prePaintWindow() can extend areas to paint, these changes would have to propagate
// up all the way from paintSimpleScreen() up to paintScreen(), so save them here rather
// than propagate them up in arguments.
QRegion painted_region;
// Additional damage that needs to be repaired to bring a reused back buffer up to date
QRegion repaint_region;
// The dirty region before it was unioned with repaint_region
QRegion damaged_region;
// The screen that is being currently painted
int painted_screen = -1;
// windows in their stacking order
QVector< Window* > stacking_order;
private:
void paintWindowThumbnails(Scene::Window *w, const QRegion &region, qreal opacity, qreal brightness, qreal saturation);
void paintDesktopThumbnails(Scene::Window *w);
Provide expected presentation time to effects Effects are given the interval between two consecutive frames. The main flaw of this approach is that if the Compositor transitions from the idle state to "active" state, i.e. when there is something to repaint, effects may see a very large interval between the last painted frame and the current. In order to address this issue, the Scene invalidates the timer that is used to measure time between consecutive frames before the Compositor is about to become idle. While this works perfectly fine with Xinerama-style rendering, with per screen rendering, determining whether the compositor is about to idle is rather a tedious task mostly because a single output can't be used for the test. Furthermore, since the Compositor schedules pointless repaints just to ensure that it's idle, it might take several attempts to figure out whether the scene timer must be invalidated if you use (true) per screen rendering. Ideally, all effects should use a timeline helper that is aware of the underlying render loop and its timings. However, this option is off the table because it will involve a lot of work to implement it. Alternative and much simpler option is to pass the expected presentation time to effects rather than time between consecutive frames. This means that effects are responsible for determining how much animation timelines have to be advanced. Typically, an effect would have to store the presentation timestamp provided in either prePaint{Screen,Window} and use it in the subsequent prePaint{Screen,Window} call to estimate the amount of time passed between the next and the last frames. Unfortunately, this is an API incompatible change. However, it shouldn't take a lot of work to port third-party binary effects, which don't use the AnimationEffect class, to the new API. On the bright side, we no longer need to be concerned about the Compositor getting idle. We do still try to determine whether the Compositor is about to idle, primarily, because the OpenGL render backend swaps buffers on present, but that will change with the ongoing compositing timing rework.
2020-11-20 15:44:04 +00:00
std::chrono::milliseconds m_expectedPresentTimestamp = std::chrono::milliseconds::zero();
void reallocRepaints();
QHash< Toplevel*, Window* > m_windows;
QVector<QRegion> m_repaints;
// how many times finalPaintScreen() has been called
int m_paintScreenCount = 0;
2011-01-30 14:34:42 +00:00
};
Move SceneXRender into a plugin Summary: First step for loading the compositor Scenes through plugins. The general idea is that we currently needlessly pull in all the Scenes although only one will be used. E.g. on X11 we pull in QPainter, although they are not compatible. On Wayland we pull in XRender although they are not compatible. Furthermore our current Scene creation strategy is not really fault tolerant and can create situations where we don't get a compositor. E.g on fbdev backend the default settings won't work as it does not support OpenGL. Long term I want to tackle those conceptional problems together: we try to load all plugins supported by the current platform till we have a scene which works. Thus on Wayland we don't end up in a situation where we don't have a working compositor because the configuration is bad. To make this possible the switch statement in the Scene needs to go and needs to be replaced by a for loop iterating over all the available scenes on the platform. If we go there it makes sense to replace it directly with a plugin based approach. So this is a change which tackles the problem by first introducing the plugin loading. The xrender based scene (as it's the most simple one) is moved into a plugin. It is first tried to find a scene plugin and only if there is none the existing code is used. Test Plan: Tested all scenes Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7232
2017-08-10 16:13:42 +00:00
/**
* Factory class to create a Scene. Needs to be implemented by the plugins.
*/
Move SceneXRender into a plugin Summary: First step for loading the compositor Scenes through plugins. The general idea is that we currently needlessly pull in all the Scenes although only one will be used. E.g. on X11 we pull in QPainter, although they are not compatible. On Wayland we pull in XRender although they are not compatible. Furthermore our current Scene creation strategy is not really fault tolerant and can create situations where we don't get a compositor. E.g on fbdev backend the default settings won't work as it does not support OpenGL. Long term I want to tackle those conceptional problems together: we try to load all plugins supported by the current platform till we have a scene which works. Thus on Wayland we don't end up in a situation where we don't have a working compositor because the configuration is bad. To make this possible the switch statement in the Scene needs to go and needs to be replaced by a for loop iterating over all the available scenes on the platform. If we go there it makes sense to replace it directly with a plugin based approach. So this is a change which tackles the problem by first introducing the plugin loading. The xrender based scene (as it's the most simple one) is moved into a plugin. It is first tried to find a scene plugin and only if there is none the existing code is used. Test Plan: Tested all scenes Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7232
2017-08-10 16:13:42 +00:00
class KWIN_EXPORT SceneFactory : public QObject
{
Q_OBJECT
public:
Run clang-tidy with modernize-use-override check Summary: Currently code base of kwin can be viewed as two pieces. One is very ancient, and the other one is more modern, which uses new C++ features. The main problem with the ancient code is that it was written before C++11 era. So, no override or final keywords, lambdas, etc. Quite recently, KDE compiler settings were changed to show a warning if a virtual method has missing override keyword. As you might have already guessed, this fired back at us because of that ancient code. We had about 500 new compiler warnings. A "solution" was proposed to that problem - disable -Wno-suggest-override and the other similar warning for clang. It's hard to call a solution because those warnings are disabled not only for the old code, but also for new. This is not what we want! The main argument for not actually fixing the problem was that git history will be screwed as well because of human factor. While good git history is a very important thing, we should not go crazy about it and block every change that somehow alters git history. git blame allows to specify starting revision for a reason. The other argument (human factor) can be easily solved by using tools such as clang-tidy. clang-tidy is a clang-based linter for C++. It can be used for various things, e.g. fixing coding style(e.g. add missing braces to if statements, readability-braces-around-statements check), or in our case add missing override keywords. Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, apol, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 16:52:26 +00:00
~SceneFactory() override;
Move SceneXRender into a plugin Summary: First step for loading the compositor Scenes through plugins. The general idea is that we currently needlessly pull in all the Scenes although only one will be used. E.g. on X11 we pull in QPainter, although they are not compatible. On Wayland we pull in XRender although they are not compatible. Furthermore our current Scene creation strategy is not really fault tolerant and can create situations where we don't get a compositor. E.g on fbdev backend the default settings won't work as it does not support OpenGL. Long term I want to tackle those conceptional problems together: we try to load all plugins supported by the current platform till we have a scene which works. Thus on Wayland we don't end up in a situation where we don't have a working compositor because the configuration is bad. To make this possible the switch statement in the Scene needs to go and needs to be replaced by a for loop iterating over all the available scenes on the platform. If we go there it makes sense to replace it directly with a plugin based approach. So this is a change which tackles the problem by first introducing the plugin loading. The xrender based scene (as it's the most simple one) is moved into a plugin. It is first tried to find a scene plugin and only if there is none the existing code is used. Test Plan: Tested all scenes Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7232
2017-08-10 16:13:42 +00:00
/**
* @returns The created Scene, may be @c nullptr.
*/
Move SceneXRender into a plugin Summary: First step for loading the compositor Scenes through plugins. The general idea is that we currently needlessly pull in all the Scenes although only one will be used. E.g. on X11 we pull in QPainter, although they are not compatible. On Wayland we pull in XRender although they are not compatible. Furthermore our current Scene creation strategy is not really fault tolerant and can create situations where we don't get a compositor. E.g on fbdev backend the default settings won't work as it does not support OpenGL. Long term I want to tackle those conceptional problems together: we try to load all plugins supported by the current platform till we have a scene which works. Thus on Wayland we don't end up in a situation where we don't have a working compositor because the configuration is bad. To make this possible the switch statement in the Scene needs to go and needs to be replaced by a for loop iterating over all the available scenes on the platform. If we go there it makes sense to replace it directly with a plugin based approach. So this is a change which tackles the problem by first introducing the plugin loading. The xrender based scene (as it's the most simple one) is moved into a plugin. It is first tried to find a scene plugin and only if there is none the existing code is used. Test Plan: Tested all scenes Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7232
2017-08-10 16:13:42 +00:00
virtual Scene *create(QObject *parent = nullptr) const = 0;
protected:
explicit SceneFactory(QObject *parent);
};
// The base class for windows representations in composite backends
class Scene::Window : public QObject
2011-01-30 14:34:42 +00:00
{
Q_OBJECT
2011-01-30 14:34:42 +00:00
public:
explicit Window(Toplevel *client, QObject *parent = nullptr);
~Window() override;
2011-01-30 14:34:42 +00:00
// perform the actual painting of the window
virtual void performPaint(int mask, const QRegion &region, const WindowPaintData &data) = 0;
2011-01-30 14:34:42 +00:00
int x() const;
int y() const;
int width() const;
int height() const;
QRect geometry() const;
QPoint pos() const;
QSize size() const;
QRect rect() const;
// access to the internal window class
// TODO eventually get rid of this
Toplevel* window() const;
2011-01-30 14:34:42 +00:00
// should the window be painted
bool isPaintingEnabled() const;
void resetPaintingEnabled();
// Flags explaining why painting should be disabled
enum {
// Window will not be painted
PAINT_DISABLED = 1 << 0,
// Window will not be painted because it is deleted
PAINT_DISABLED_BY_DELETE = 1 << 1,
// Window will not be painted because of which desktop it's on
PAINT_DISABLED_BY_DESKTOP = 1 << 2,
// Window will not be painted because it is minimized
PAINT_DISABLED_BY_MINIMIZE = 1 << 3,
// Window will not be painted because it's not on the current activity
PAINT_DISABLED_BY_ACTIVITY = 1 << 5
};
2011-01-30 14:34:42 +00:00
void enablePainting(int reason);
void disablePainting(int reason);
// is the window visible at all
bool isVisible() const;
// is the window fully opaque
bool isOpaque() const;
QRegion decorationShape() const;
void updateToplevel(Deleted *deleted);
void referencePreviousPixmap();
void unreferencePreviousPixmap();
WindowItem *windowItem() const;
SurfaceItem *surfaceItem() const;
ShadowItem *shadowItem() const;
virtual QSharedPointer<GLTexture> windowTexture() {
return {};
}
protected:
2011-01-30 14:34:42 +00:00
Toplevel* toplevel;
ImageFilterType filter;
private:
void referencePreviousPixmap_helper(SurfaceItem *item);
void unreferencePreviousPixmap_helper(SurfaceItem *item);
void updateWindowPosition();
2011-01-30 14:34:42 +00:00
int disable_painting;
QScopedPointer<WindowItem> m_windowItem;
2011-01-30 14:34:42 +00:00
Q_DISABLE_COPY(Window)
};
class Scene::EffectFrame
2011-01-30 14:34:42 +00:00
{
public:
EffectFrame(EffectFrameImpl* frame);
virtual ~EffectFrame();
virtual void render(const QRegion &region, double opacity, double frameOpacity) = 0;
2011-01-30 14:34:42 +00:00
virtual void free() = 0;
virtual void freeIconFrame() = 0;
virtual void freeTextFrame() = 0;
virtual void freeSelection() = 0;
virtual void crossFadeIcon() = 0;
virtual void crossFadeText() = 0;
protected:
EffectFrameImpl* m_effectFrame;
};
inline
int Scene::Window::x() const
2011-01-30 14:34:42 +00:00
{
return toplevel->x();
2011-01-30 14:34:42 +00:00
}
inline
int Scene::Window::y() const
2011-01-30 14:34:42 +00:00
{
return toplevel->y();
2011-01-30 14:34:42 +00:00
}
inline
int Scene::Window::width() const
2011-01-30 14:34:42 +00:00
{
return toplevel->width();
2011-01-30 14:34:42 +00:00
}
inline
int Scene::Window::height() const
2011-01-30 14:34:42 +00:00
{
return toplevel->height();
2011-01-30 14:34:42 +00:00
}
inline
QRect Scene::Window::geometry() const
2011-01-30 14:34:42 +00:00
{
return toplevel->frameGeometry();
2011-01-30 14:34:42 +00:00
}
inline
QSize Scene::Window::size() const
2011-01-30 14:34:42 +00:00
{
return toplevel->size();
2011-01-30 14:34:42 +00:00
}
inline
QPoint Scene::Window::pos() const
2011-01-30 14:34:42 +00:00
{
return toplevel->pos();
2011-01-30 14:34:42 +00:00
}
inline
QRect Scene::Window::rect() const
2011-01-30 14:34:42 +00:00
{
return toplevel->rect();
2011-01-30 14:34:42 +00:00
}
inline
Toplevel* Scene::Window::window() const
2011-01-30 14:34:42 +00:00
{
return toplevel;
2011-01-30 14:34:42 +00:00
}
} // namespace
Move SceneXRender into a plugin Summary: First step for loading the compositor Scenes through plugins. The general idea is that we currently needlessly pull in all the Scenes although only one will be used. E.g. on X11 we pull in QPainter, although they are not compatible. On Wayland we pull in XRender although they are not compatible. Furthermore our current Scene creation strategy is not really fault tolerant and can create situations where we don't get a compositor. E.g on fbdev backend the default settings won't work as it does not support OpenGL. Long term I want to tackle those conceptional problems together: we try to load all plugins supported by the current platform till we have a scene which works. Thus on Wayland we don't end up in a situation where we don't have a working compositor because the configuration is bad. To make this possible the switch statement in the Scene needs to go and needs to be replaced by a for loop iterating over all the available scenes on the platform. If we go there it makes sense to replace it directly with a plugin based approach. So this is a change which tackles the problem by first introducing the plugin loading. The xrender based scene (as it's the most simple one) is moved into a plugin. It is first tried to find a scene plugin and only if there is none the existing code is used. Test Plan: Tested all scenes Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7232
2017-08-10 16:13:42 +00:00
Q_DECLARE_INTERFACE(KWin::SceneFactory, "org.kde.kwin.Scene")
#endif