yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kwin/src/scene.h

419 lines
12 KiB
C
Raw Normal View History

Prettify license headers
2020-08-02 22:22:19 +00:00
/*
KWin - the KDE window manager
This file is part of the KDE project.
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 2006 Lubos Lunak <l.lunak@kde.org>
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
#ifndef KWIN_SCENE_H
#define KWIN_SCENE_H
Introduce render layers This is the first tiny step towards the layer-based compositing in kwin. The RenderLayer represents a layer with some contents. The actual contents is represented by the RenderLayerDelegate class. Currently, the RenderLayer is just a simple class responsible for geometry, and repaints, but it will grow in the future. For example, render layers need to form a tree. The next (missing) biggest component in the layer-based compositing are output layers. When output layers are added, each render layer would have an output layer assigned to it or have its output layer inherited from the parent. The render layer tree wouldn't be affected by changes to the output layer tree so transition between software and hardware cursors can be seamless. The next big milestone will be to try to port some of existing kwin functionality to the RenderLayer, e.g. software cursor or screen edges.
2022-02-04 18:38:37 +00:00
#include "renderlayerdelegate.h"
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
#include "toplevel.h"
Move utils.h file to utils directory
2022-01-18 08:35:52 +00:00
#include "utils/common.h"
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
#include "kwineffects.h"
Cleanup and reorder includes in toplevel.h REVIEW: 110202
2013-04-26 09:27:30 +00:00
#include <QElapsedTimer>
Pass projection matrix to ScreenPaintData With this change a new ctor overload is added to ScreenPaintData which allows passing a projection matrix through the effects. This allows effects to put up custom shaders with a shared projection matrix and without having to calculate it themselves. The projection matrix is a read-only information for the effects. There is no way to change or overwrite it.
2015-11-26 15:12:12 +00:00
#include <QMatrix4x4>
Cleanup and reorder includes in toplevel.h REVIEW: 110202
2013-04-26 09:27:30 +00:00
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
namespace KWin
{
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 11:11:19 +00:00
namespace Decoration
{
class DecoratedClientImpl;
}
scene: Introduce window items Currently, dealing with sub-surfaces is very difficult due to the scene design being heavily influenced by X11 requirements. The goal of this change is to re-work scene abstractions to make improving the wayland support easier. The Item class is based on the QQuickItem class. My hope is that one day we will be able to transition to QtQuick for painting scene, but in meanwhile it makes more sense to have a minimalistic internal item class. The WindowItem class represents a window. The SurfaceItem class represents the contents of either an X11, or a Wayland, or an internal surface. The DecorationItem and the ShadowItem class represent the server-side deco and drop-shadow, respectively. At the moment, the SurfaceItem is bound to the scene window, but the long term plan is to break that connection so we could re-use the SurfaceItem for things such as software cursors and drag-and-drop additional icons. One of the responsibilities of the Item is to schedule repaints as needed. Ideally, there shouldn't be any addRepaint() calls in the core code. The Item class schedules repaints on geometry updates. In the future, it also has to request an update if its opacity or visibility changes.
2021-02-04 09:07:20 +00:00
class AbstractOutput;
Move decoration renderer to decoration item Currently, the implementation of the DecoratedClient and the decoration renderer are strongly coupled. This poses a problem with the item based design as the ultimate goal is to have scene items construct paint nodes which are then fed to the renderer. The DecorationItem has to have control over the decoration texture. Another issue is that the scene cannot smoothly cross-fade between two window states if the decoration is removed, e.g. from fullscreen mode to normal and vice versa. This change moves the decoration renderer to the decoration item. With the introduction of a generic scene texture atlas, we hope to get rid of the decoration renderer altogether.
2021-04-26 16:38:40 +00:00
class DecorationRenderer;
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
class Deleted;
Refactoring of EffectFrame: EffectFrame becomes an interface just like EffectsHandler and EffectWindow and a concrete EffectFrameImpl in core. Rendering of the EffectFrame is moved into the scene as Scene::EffectFrame with a concrete implementation in SceneXrender and SceneOpenGL. A factory method for an EffectFrame is added to the EffectsHandler, which is used by the effects. Next step: pass the EffectFrame through all effects, so that effects can transform, blur, invert whatever it. svn path=/trunk/KDE/kdebase/workspace/; revision=1151271
2010-07-18 16:32:37 +00:00
class EffectFrameImpl;
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
class EffectWindowImpl;
scene: Introduce window items Currently, dealing with sub-surfaces is very difficult due to the scene design being heavily influenced by X11 requirements. The goal of this change is to re-work scene abstractions to make improving the wayland support easier. The Item class is based on the QQuickItem class. My hope is that one day we will be able to transition to QtQuick for painting scene, but in meanwhile it makes more sense to have a minimalistic internal item class. The WindowItem class represents a window. The SurfaceItem class represents the contents of either an X11, or a Wayland, or an internal surface. The DecorationItem and the ShadowItem class represent the server-side deco and drop-shadow, respectively. At the moment, the SurfaceItem is bound to the scene window, but the long term plan is to break that connection so we could re-use the SurfaceItem for things such as software cursors and drag-and-drop additional icons. One of the responsibilities of the Item is to schedule repaints as needed. Ideally, there shouldn't be any addRepaint() calls in the core code. The Item class schedules repaints on geometry updates. In the future, it also has to request an update if its opacity or visibility changes.
2021-02-04 09:07:20 +00:00
class GLTexture;
class Item;
Fix recorded render time when glXSwapBuffers() blocks If glXSwapBuffers() blocks, the render loop will also record how long kwin was blocked. Obviously, we don't want that.
2021-01-26 12:18:29 +00:00
class RenderLoop;
Introduce render layers This is the first tiny step towards the layer-based compositing in kwin. The RenderLayer represents a layer with some contents. The actual contents is represented by the RenderLayerDelegate class. Currently, the RenderLayer is just a simple class responsible for geometry, and repaints, but it will grow in the future. For example, render layers need to form a tree. The next (missing) biggest component in the layer-based compositing are output layers. When output layers are added, each render layer would have an output layer assigned to it or have its output layer inherited from the parent. The render layer tree wouldn't be affected by changes to the output layer tree so transition between software and hardware cursors can be seamless. The next big milestone will be to try to port some of existing kwin functionality to the RenderLayer, e.g. software cursor or screen edges.
2022-02-04 18:38:37 +00:00
class Scene;
Move ownership on Shadow from Toplevel to Scene::Window The Shadow is clearly an aspect of the compositor. Therefore the Shadow has to be owned and controlled by the Scene::Window. Nevertheless Toplevel needs to know about the Shadow cause of reading the property.
2011-04-03 09:31:33 +00:00
class Shadow;
scene: Introduce window items Currently, dealing with sub-surfaces is very difficult due to the scene design being heavily influenced by X11 requirements. The goal of this change is to re-work scene abstractions to make improving the wayland support easier. The Item class is based on the QQuickItem class. My hope is that one day we will be able to transition to QtQuick for painting scene, but in meanwhile it makes more sense to have a minimalistic internal item class. The WindowItem class represents a window. The SurfaceItem class represents the contents of either an X11, or a Wayland, or an internal surface. The DecorationItem and the ShadowItem class represent the server-side deco and drop-shadow, respectively. At the moment, the SurfaceItem is bound to the scene window, but the long term plan is to break that connection so we could re-use the SurfaceItem for things such as software cursors and drag-and-drop additional icons. One of the responsibilities of the Item is to schedule repaints as needed. Ideally, there shouldn't be any addRepaint() calls in the core code. The Item class schedules repaints on geometry updates. In the future, it also has to request an update if its opacity or visibility changes.
2021-02-04 09:07:20 +00:00
class ShadowItem;
class SurfaceItem;
Decouple window pixmaps from scene windows One of the scene redesign goals is to make wayland surface items re-usable. So we have the same rendering path for drag-and-drop icons, software cursors, and window surfaces. The biggest issue at the moment is that window pixmaps are tightly coupled with scene windows. This change de-couples window pixmaps from scene windows. In order to achieve that, some architecture changes were made. The WindowPixmap class was replaced with the SurfacePixmap class. A surface pixmap is created by a surface item. Under the hood, a SurfacePixmap will create a PlatformSurfaceTexture object, which contains all the information necessary for the renderer. The SceneOpenGLTexture class was removed. However, the GLX and the EGL on X11 backends still mess with GLTexture's internals.
2021-04-09 07:06:04 +00:00
class SurfacePixmapInternal;
class SurfacePixmapWayland;
class SurfacePixmapX11;
Rename PlatformSurfaceTexture to SurfaceTexture This is, primarily, to make naming consistent with SurfaceItem, SurfacePixmap and just "Surface" in the future.
2021-10-20 14:58:58 +00:00
class SurfaceTexture;
scene: Introduce window items Currently, dealing with sub-surfaces is very difficult due to the scene design being heavily influenced by X11 requirements. The goal of this change is to re-work scene abstractions to make improving the wayland support easier. The Item class is based on the QQuickItem class. My hope is that one day we will be able to transition to QtQuick for painting scene, but in meanwhile it makes more sense to have a minimalistic internal item class. The WindowItem class represents a window. The SurfaceItem class represents the contents of either an X11, or a Wayland, or an internal surface. The DecorationItem and the ShadowItem class represent the server-side deco and drop-shadow, respectively. At the moment, the SurfaceItem is bound to the scene window, but the long term plan is to break that connection so we could re-use the SurfaceItem for things such as software cursors and drag-and-drop additional icons. One of the responsibilities of the Item is to schedule repaints as needed. Ideally, there shouldn't be any addRepaint() calls in the core code. The Item class schedules repaints on geometry updates. In the future, it also has to request an update if its opacity or visibility changes.
2021-02-04 09:07:20 +00:00
class WindowItem;
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Introduce render layers This is the first tiny step towards the layer-based compositing in kwin. The RenderLayer represents a layer with some contents. The actual contents is represented by the RenderLayerDelegate class. Currently, the RenderLayer is just a simple class responsible for geometry, and repaints, but it will grow in the future. For example, render layers need to form a tree. The next (missing) biggest component in the layer-based compositing are output layers. When output layers are added, each render layer would have an output layer assigned to it or have its output layer inherited from the parent. The render layer tree wouldn't be affected by changes to the output layer tree so transition between software and hardware cursors can be seamless. The next big milestone will be to try to port some of existing kwin functionality to the RenderLayer, e.g. software cursor or screen edges.
2022-02-04 18:38:37 +00:00
class SceneDelegate : public RenderLayerDelegate
{
Q_OBJECT
public:
explicit SceneDelegate(Scene *scene, QObject *parent = nullptr);
explicit SceneDelegate(Scene *scene, AbstractOutput *output, QObject *parent = nullptr);
~SceneDelegate() override;
scene: Rework surface damage tracking It's not possible to get the surface damage before calling Scene::paint(), which is a big problem because it blocks proper surface damage and buffer damage calculation when walking render layer tree. This change reworks the scene compositing stages to allow getting the next surface damage before calling Scene::paint(). The main challenge is that the effects can expand the surface damage. We have to call prePaintWindow() and prePaintScreen() before actually starting painting. However, prePaintWindow() is called after starting rendering. This change makes Scene call prePaintWindow() and prePaintScreen() so it's possible to know the surface damage beforehand. Unfortunately, it's also a breaking change. Some fullscreen effects will have to adapt to the new Scene paint order. Paint hooks will be invoked in the following order: * prePaintScreen() once per frame * prePaintWindow() once per frame * paintScreen() can be called multiple times * paintWindow() can be called as many times as paintScreen() * postPaintWindow() once per frame * postPaintScreen() once per frame After walking the render layer tree, the Compositor will poke the render backend for the back buffer repair region and combine it with the surface damage to get the buffer damage, which can be passed to the render backend (in order to optimize performance with tiled gpus) and Scene::paint(), which will determine what parts of the scene have to repainted based on the buffer damage.
2022-02-16 17:13:57 +00:00
QRegion repaints() const override;
Introduce render layers This is the first tiny step towards the layer-based compositing in kwin. The RenderLayer represents a layer with some contents. The actual contents is represented by the RenderLayerDelegate class. Currently, the RenderLayer is just a simple class responsible for geometry, and repaints, but it will grow in the future. For example, render layers need to form a tree. The next (missing) biggest component in the layer-based compositing are output layers. When output layers are added, each render layer would have an output layer assigned to it or have its output layer inherited from the parent. The render layer tree wouldn't be affected by changes to the output layer tree so transition between software and hardware cursors can be seamless. The next big milestone will be to try to port some of existing kwin functionality to the RenderLayer, e.g. software cursor or screen edges.
2022-02-04 18:38:37 +00:00
SurfaceItem *scanoutCandidate() const override;
void prePaint() override;
void postPaint() override;
scene: Rework surface damage tracking It's not possible to get the surface damage before calling Scene::paint(), which is a big problem because it blocks proper surface damage and buffer damage calculation when walking render layer tree. This change reworks the scene compositing stages to allow getting the next surface damage before calling Scene::paint(). The main challenge is that the effects can expand the surface damage. We have to call prePaintWindow() and prePaintScreen() before actually starting painting. However, prePaintWindow() is called after starting rendering. This change makes Scene call prePaintWindow() and prePaintScreen() so it's possible to know the surface damage beforehand. Unfortunately, it's also a breaking change. Some fullscreen effects will have to adapt to the new Scene paint order. Paint hooks will be invoked in the following order: * prePaintScreen() once per frame * prePaintWindow() once per frame * paintScreen() can be called multiple times * paintWindow() can be called as many times as paintScreen() * postPaintWindow() once per frame * postPaintScreen() once per frame After walking the render layer tree, the Compositor will poke the render backend for the back buffer repair region and combine it with the surface damage to get the buffer damage, which can be passed to the render backend (in order to optimize performance with tiled gpus) and Scene::paint(), which will determine what parts of the scene have to repainted based on the buffer damage.
2022-02-16 17:13:57 +00:00
void paint(const QRegion &region) override;
Introduce render layers This is the first tiny step towards the layer-based compositing in kwin. The RenderLayer represents a layer with some contents. The actual contents is represented by the RenderLayerDelegate class. Currently, the RenderLayer is just a simple class responsible for geometry, and repaints, but it will grow in the future. For example, render layers need to form a tree. The next (missing) biggest component in the layer-based compositing are output layers. When output layers are added, each render layer would have an output layer assigned to it or have its output layer inherited from the parent. The render layer tree wouldn't be affected by changes to the output layer tree so transition between software and hardware cursors can be seamless. The next big milestone will be to try to port some of existing kwin functionality to the RenderLayer, e.g. software cursor or screen edges.
2022-02-04 18:38:37 +00:00
private:
Scene *m_scene;
AbstractOutput *m_output = nullptr;
};
[autotests] Add a new test case which can verify the rendering of QPainter Scene Summary: The idea behind this autotest is inspired by bug 356328 which produced incorrect rendering results. Also it's inspired by openQA which performs image reference comparisons. This test case tries to go further. It creates reference images which must match the rendering result exactly. So far the test case verifies the start condition - kwin started and one frame is rendered with default cursor in the middle of the screen. And it verifies the moving of the cursor without any windows shown. Whenever the cursor moves a repaint should be triggered and the old and new area should be properly repainted. To support this the test needs some minor changes in KWin: * Scene provides a frameRendered signal - needed for waiting on frame * Scene and SceneQPainter are exported * SceneQPainter provides access to it's Backend, so that we get to the backbuffer * ScriptedEffectLoader is exported for getting a list of all scripted effects - (we don't want fade to manipulate the rendering) Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2046
2016-06-29 17:22:41 +00:00
class KWIN_EXPORT Scene : public QObject
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
Make class Scene inherit from QObject The class Scene now inherits from QObject and has the Q_OBJECT macro. The inheriting classes SceneOpenGL and SceneXRender are provided with the Q_OBJECT macro. Now it is possible to use signals and slots and replace direct method calls.
2011-06-15 16:35:00 +00:00
Q_OBJECT
Introduce render layers This is the first tiny step towards the layer-based compositing in kwin. The RenderLayer represents a layer with some contents. The actual contents is represented by the RenderLayerDelegate class. Currently, the RenderLayer is just a simple class responsible for geometry, and repaints, but it will grow in the future. For example, render layers need to form a tree. The next (missing) biggest component in the layer-based compositing are output layers. When output layers are added, each render layer would have an output layer assigned to it or have its output layer inherited from the parent. The render layer tree wouldn't be affected by changes to the output layer tree so transition between software and hardware cursors can be seamless. The next big milestone will be to try to port some of existing kwin functionality to the RenderLayer, e.g. software cursor or screen edges.
2022-02-04 18:38:37 +00:00
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
public:
Drop Workspace dependency from Scene Only used for one connect which can also be done outside of Scene. Subclasses got the singleton pointer and just passed to the parent.
2015-02-23 13:41:45 +00:00
explicit Scene(QObject *parent = nullptr);
Introduce render layers This is the first tiny step towards the layer-based compositing in kwin. The RenderLayer represents a layer with some contents. The actual contents is represented by the RenderLayerDelegate class. Currently, the RenderLayer is just a simple class responsible for geometry, and repaints, but it will grow in the future. For example, render layers need to form a tree. The next (missing) biggest component in the layer-based compositing are output layers. When output layers are added, each render layer would have an output layer assigned to it or have its output layer inherited from the parent. The render layer tree wouldn't be affected by changes to the output layer tree so transition between software and hardware cursors can be seamless. The next big milestone will be to try to port some of existing kwin functionality to the RenderLayer, e.g. software cursor or screen edges.
2022-02-04 18:38:37 +00:00
~Scene() override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
class EffectFrame;
class Window;
Move all dirty region scene repaint scheduling to Scene The Compositor contains nothing that can potentially get dirty and need repainting. As is, the advantages of this move aren't really noticeable, but it makes sense with multiple scenes. Backend parts are far from ideal, they can be improved later on as we progress with the scene redesign.
2021-11-09 10:36:24 +00:00
void initialize();
Delegate repaint scheduling to the Scene In order to unlock per screen rendering, we need to track repaints for every screen individually. While we could do this in the Compositor class, tracking repaints in the Scene seems a better alternative in long run because we will have to instantiate a Scene for each composited screen one day.
2020-11-20 09:35:38 +00:00
/**
* Schedules a repaint for the specified @a region.
*/
void addRepaint(const QRegion &region);
Move all dirty region scene repaint scheduling to Scene The Compositor contains nothing that can potentially get dirty and need repainting. As is, the advantages of this move aren't really noticeable, but it makes sense with multiple scenes. Backend parts are far from ideal, they can be improved later on as we progress with the scene redesign.
2021-11-09 10:36:24 +00:00
void addRepaint(const QRect &rect);
void addRepaint(int x, int y, int width, int height);
void addRepaintFull();
scene: Rework surface damage tracking It's not possible to get the surface damage before calling Scene::paint(), which is a big problem because it blocks proper surface damage and buffer damage calculation when walking render layer tree. This change reworks the scene compositing stages to allow getting the next surface damage before calling Scene::paint(). The main challenge is that the effects can expand the surface damage. We have to call prePaintWindow() and prePaintScreen() before actually starting painting. However, prePaintWindow() is called after starting rendering. This change makes Scene call prePaintWindow() and prePaintScreen() so it's possible to know the surface damage beforehand. Unfortunately, it's also a breaking change. Some fullscreen effects will have to adapt to the new Scene paint order. Paint hooks will be invoked in the following order: * prePaintScreen() once per frame * prePaintWindow() once per frame * paintScreen() can be called multiple times * paintWindow() can be called as many times as paintScreen() * postPaintWindow() once per frame * postPaintScreen() once per frame After walking the render layer tree, the Compositor will poke the render backend for the back buffer repair region and combine it with the surface damage to get the buffer damage, which can be passed to the render backend (in order to optimize performance with tiled gpus) and Scene::paint(), which will determine what parts of the scene have to repainted based on the buffer damage.
2022-02-16 17:13:57 +00:00
QRegion damage() const;
Delegate repaint scheduling to the Scene In order to unlock per screen rendering, we need to track repaints for every screen individually. While we could do this in the Compositor class, tracking repaints in the Scene seems a better alternative in long run because we will have to instantiate a Scene for each composited screen one day.
2020-11-20 09:35:38 +00:00
Allow specifying scene geometry The main motivation behind this change is to decouple the scene a bit further from Screens, which is also obsolete.
2021-11-24 17:18:31 +00:00
QRect geometry() const;
void setGeometry(const QRect &rect);
Introduce render layers This is the first tiny step towards the layer-based compositing in kwin. The RenderLayer represents a layer with some contents. The actual contents is represented by the RenderLayerDelegate class. Currently, the RenderLayer is just a simple class responsible for geometry, and repaints, but it will grow in the future. For example, render layers need to form a tree. The next (missing) biggest component in the layer-based compositing are output layers. When output layers are added, each render layer would have an output layer assigned to it or have its output layer inherited from the parent. The render layer tree wouldn't be affected by changes to the output layer tree so transition between software and hardware cursors can be seamless. The next big milestone will be to try to port some of existing kwin functionality to the RenderLayer, e.g. software cursor or screen edges.
2022-02-04 18:38:37 +00:00
QList<SceneDelegate *> delegates() const;
void addDelegate(SceneDelegate *delegate);
void removeDelegate(SceneDelegate *delegate);
Delegate repaint scheduling to the Scene In order to unlock per screen rendering, we need to track repaints for every screen individually. While we could do this in the Compositor class, tracking repaints in the Scene seems a better alternative in long run because we will have to instantiate a Scene for each composited screen one day.
2020-11-20 09:35:38 +00:00
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
// Returns true if the ctor failed to properly initialize.
virtual bool initFailed() const = 0;
fix flicker with fullscreen effects BUG: 304375 FIXED-IN: 4.9.1 REVIEW: 106142
2012-08-23 14:51:40 +00:00
Move direct scanout management to Compositor The responsibilities of the Scene must be reduced to painting only so we can move forward with the layer-based compositing. This change moves direct scanout logic from the opengl scene to the base scene class and the compositor. It makes the opengl scene less overloaded and allows to share direct scanout logic.
2022-02-04 17:38:58 +00:00
SurfaceItem *scanoutCandidate() const;
void prePaint(AbstractOutput *output);
void postPaint();
scene: Rework surface damage tracking It's not possible to get the surface damage before calling Scene::paint(), which is a big problem because it blocks proper surface damage and buffer damage calculation when walking render layer tree. This change reworks the scene compositing stages to allow getting the next surface damage before calling Scene::paint(). The main challenge is that the effects can expand the surface damage. We have to call prePaintWindow() and prePaintScreen() before actually starting painting. However, prePaintWindow() is called after starting rendering. This change makes Scene call prePaintWindow() and prePaintScreen() so it's possible to know the surface damage beforehand. Unfortunately, it's also a breaking change. Some fullscreen effects will have to adapt to the new Scene paint order. Paint hooks will be invoked in the following order: * prePaintScreen() once per frame * prePaintWindow() once per frame * paintScreen() can be called multiple times * paintWindow() can be called as many times as paintScreen() * postPaintWindow() once per frame * postPaintScreen() once per frame After walking the render layer tree, the Compositor will poke the render backend for the back buffer repair region and combine it with the surface damage to get the buffer damage, which can be passed to the render backend (in order to optimize performance with tiled gpus) and Scene::paint(), which will determine what parts of the scene have to repainted based on the buffer damage.
2022-02-16 17:13:57 +00:00
virtual void paint(const QRegion &region) = 0;
Make it possible for an effect to render a screen Useful in case it needs the contents of the screen but they can't be blitted, as the state of the framebuffer is unknown.
2021-07-28 15:14:25 +00:00
Add addToplevel and removeToplevel to Scene Summary: Code that destroys all scene windows when finishing compositing is not readable. E.g. can you tell what this piece of code is doing without looking into the source code of Scene::windowClosed? foreach (Client * c, Workspace::self()->clientList()) m_scene->windowClosed(c, NULL); This change intoduces removeToplevel(as well its counterpart) method to the Scene class. The name of the new method much better describes what we're doing. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18210
2019-01-11 18:55:17 +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.
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
Add addToplevel and removeToplevel to Scene Summary: Code that destroys all scene windows when finishing compositing is not readable. E.g. can you tell what this piece of code is doing without looking into the source code of Scene::windowClosed? foreach (Client * c, Workspace::self()->clientList()) m_scene->windowClosed(c, NULL); This change intoduces removeToplevel(as well its counterpart) method to the Scene class. The name of the new method much better describes what we're doing. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18210
2019-01-11 18:55:17 +00:00
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.
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
Add addToplevel and removeToplevel to Scene Summary: Code that destroys all scene windows when finishing compositing is not readable. E.g. can you tell what this piece of code is doing without looking into the source code of Scene::windowClosed? foreach (Client * c, Workspace::self()->clientList()) m_scene->windowClosed(c, NULL); This change intoduces removeToplevel(as well its counterpart) method to the Scene class. The name of the new method much better describes what we're doing. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18210
2019-01-11 18:55:17 +00:00
void removeToplevel(Toplevel *toplevel);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Pass creation of Scene::EffectFrame to the Scene Instead of having the EffectFrameImpl check the compositor type and do the decision which Scene::EffectFrame to create, a pure virtual method in Scene is called which returns the specific Scene::EffectFrame.
2013-06-24 06:49:24 +00:00
/**
* @brief Creates the Scene backend of an EffectFrame.
*
* @param frame The EffectFrame this Scene::EffectFrame belongs to.
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
Pass creation of Scene::EffectFrame to the Scene Instead of having the EffectFrameImpl check the compositor type and do the decision which Scene::EffectFrame to create, a pure virtual method in Scene is called which returns the specific Scene::EffectFrame.
2013-06-24 06:49:24 +00:00
virtual Scene::EffectFrame *createEffectFrame(EffectFrameImpl *frame) = 0;
Pass creation of Shadow sub class instance to Scene Instead of having the Shadow factory method check the compositor type and do the decision which Shadow sub class to create, a pure virtual method in Scene is called which returns the specific Shadow sub class instance.
2013-06-24 07:06:50 +00:00
/**
* @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.
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
Pass creation of Shadow sub class instance to Scene Instead of having the Shadow factory method check the compositor type and do the decision which Shadow sub class to create, a pure virtual method in Scene is called which returns the specific Shadow sub class instance.
2013-06-24 07:06:50 +00:00
virtual Shadow *createShadow(Toplevel *toplevel) = 0;
KWin uses kdelibs coding style.
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,
kwin: simplifying paintSimpleScreen This patch reduces the number of QRegion and WindowQuadList operations by drawing the opaque and translucent parts of the window within the same bottom to top pass. REVIEW: 103671
2012-01-10 17:56:14 +00:00
// PAINT_DECORATION_ONLY = 1 << 7 has been removed
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
// Window will be painted with a lanczos filter.
Fix warning
2012-03-02 13:03:05 +00:00
PAINT_WINDOW_LANCZOS = 1 << 8
kwin:remove PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS_WITHOUT_FULL_REPAINTS paintSimpleScreen can handle the affected effects now. REVIEW: 103827
2012-01-29 16:25:20 +00:00
// PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS_WITHOUT_FULL_REPAINTS = 1 << 9 has been removed
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +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
virtual bool makeOpenGLContextCurrent();
virtual void doneOpenGLContextCurrent();
screencast: Use fences to avoid stalling the graphics pipeline Currently, we use glFinish() to ensure that stream consumers don't see corrupted or rather incomplete buffers. This is a serious issue because glFinish() not only prevents the gpu from processing new GL commands, but it also blocks the compositor. This change addresses the blocking issue by using native fences. With the proposed change, after finishing recording a frame, a fence is inserted in the command stream. When the native fence is signaled, the pending pipewire buffer will be enqueued. If the EGL_ANDROID_native_fence_sync extension is not supported, we'll fall back to using glFinish().
2020-10-15 09:27:00 +00:00
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
[kwineffects] Pass screen projection matrix to WindowPaintData The screen projection matrix is needed if an effect wants to customize the modelview projection matrix while rendering a window and keeping the currently applied screen projection and transformation.
2015-11-30 13:35:12 +00:00
virtual QMatrix4x4 screenProjectionMatrix() const;
Move decoration renderer to decoration item Currently, the implementation of the DecoratedClient and the decoration renderer are strongly coupled. This poses a problem with the item based design as the ultimate goal is to have scene items construct paint nodes which are then fed to the renderer. The DecorationItem has to have control over the decoration texture. Another issue is that the scene cannot smoothly cross-fade between two window states if the decoration is removed, e.g. from fullscreen mode to normal and vice versa. This change moves the decoration renderer to the decoration item. With the introduction of a generic scene texture atlas, we hope to get rid of the decoration renderer altogether.
2021-04-26 16:38:40 +00:00
virtual DecorationRenderer *createDecorationRenderer(Decoration::DecoratedClientImpl *) = 0;
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 11:11:19 +00:00
Introduce an EffectsHandler::animationsSupported -> bool Summary: A new method to tell the effects system whether the compositor scene is able to drive animations. E.g. on software emulation (llvmpipe) it's better to not do any animations at all. This information can be used by effects to adjust their behavior, e.g. PresentWindows could skip transitions or effects can use it in their supported check to completely disable themselves. As a first step all scripted effects are considered to be unsupported if animations are not supported. They inherit AnimationEffect and are all about driving animations. The information whether animations are supported comes from the Scene. It's implemented in the following way: * XRender: animations are always supported * QPainter: animations are never supported * OpenGL: animations are supported, except for software emulation In addition - for easier testing - there is a new env variable KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection. Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D2386
2016-08-10 07:24:53 +00:00
/**
* 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.
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
Introduce an EffectsHandler::animationsSupported -> bool Summary: A new method to tell the effects system whether the compositor scene is able to drive animations. E.g. on software emulation (llvmpipe) it's better to not do any animations at all. This information can be used by effects to adjust their behavior, e.g. PresentWindows could skip transitions or effects can use it in their supported check to completely disable themselves. As a first step all scripted effects are considered to be unsupported if animations are not supported. They inherit AnimationEffect and are all about driving animations. The information whether animations are supported comes from the Scene. It's implemented in the following way: * XRender: animations are always supported * QPainter: animations are never supported * OpenGL: animations are supported, except for software emulation In addition - for easier testing - there is a new env variable KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection. Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D2386
2016-08-10 07:24:53 +00:00
virtual bool animationsSupported() const = 0;
Add virtual Scene::scenePainter method Summary: So far EffectsHandlerImpl directly accessed SceneQPainter::painter through a dynamic cast. If in future the QPainter based compositor should be moved into a plugin we cannot access it through a dynamic cast. To solve this problem the painter method is moved into Scene as a virtual method returning a sane default value. Reviewers: #kwin, #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D7214
2017-08-09 04:56:23 +00:00
/**
* The QPainter used by a QPainter based compositor scene.
* Default implementation returns @c nullptr;
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
Add virtual Scene::scenePainter method Summary: So far EffectsHandlerImpl directly accessed SceneQPainter::painter through a dynamic cast. If in future the QPainter based compositor should be moved into a plugin we cannot access it through a dynamic cast. To solve this problem the painter method is moved into Scene as a virtual method returning a sane default value. Reviewers: #kwin, #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D7214
2017-08-09 04:56:23 +00:00
virtual QPainter *scenePainter() const;
Provide a virtual Scene::qpainterRenderBuffer() -> QImage* method Needed by testing of QPainter scene to access the back buffer. Exposed as a virtual method in Scene, so that the test does not have to cast to SceneQPainter.
2017-08-11 12:59:09 +00:00
/**
* The render buffer used by a QPainter based compositor.
* Default implementation returns @c nullptr.
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
Port screenId based rendering methods to AbstractOutput
2021-08-24 20:55:42 +00:00
virtual QImage *qpainterRenderBuffer(AbstractOutput *output) const;
Provide a virtual Scene::qpainterRenderBuffer() -> QImage* method Needed by testing of QPainter scene to access the back buffer. Exposed as a virtual method in Scene, so that the test does not have to cast to SceneQPainter.
2017-08-11 12:59:09 +00:00
Add virtual method to Scene to get the EGL/GLX extensions Summary: We had a few places (e.g. DebugConsole, Platform) where the Scene was cased into a SceneOpenGL to access the backend and get the extensions. This change simplifies that by adding a virtual method to Scene directly which is implemented in SceneOpenGL and returns the backend's extensions. Thus the casts to SceneOpenGL are no longer required. Test Plan: Opened debug console to verify extensions are listed, triggered Outline to verify the sharing QPA context gets created. Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7734
2017-09-08 13:49:52 +00:00
/**
* The backend specific extensions (e.g. EGL/GLX extensions).
*
* Not the OpenGL (ES) extension!
*
* Default implementation returns empty list
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
Add virtual method to Scene to get the EGL/GLX extensions Summary: We had a few places (e.g. DebugConsole, Platform) where the Scene was cased into a SceneOpenGL to access the backend and get the extensions. This change simplifies that by adding a virtual method to Scene directly which is implemented in SceneOpenGL and returns the backend's extensions. Thus the casts to SceneOpenGL are no longer required. Test Plan: Opened debug console to verify extensions are listed, triggered Outline to verify the sharing QPA context gets created. Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7734
2017-09-08 13:49:52 +00:00
virtual QVector<QByteArray> openGLPlatformInterfaceExtensions() const;
screencasting: Expose necessary information to implement efficient screencasting
2020-07-22 17:22:36 +00:00
virtual QSharedPointer<GLTexture> textureForOutput(AbstractOutput *output) const {
Q_UNUSED(output);
return {};
}
Rename PlatformSurfaceTexture to SurfaceTexture This is, primarily, to make naming consistent with SurfaceItem, SurfacePixmap and just "Surface" in the future.
2021-10-20 14:58:58 +00:00
virtual SurfaceTexture *createSurfaceTextureInternal(SurfacePixmapInternal *pixmap);
virtual SurfaceTexture *createSurfaceTextureX11(SurfacePixmapX11 *pixmap);
virtual SurfaceTexture *createSurfaceTextureWayland(SurfacePixmapWayland *pixmap);
Decouple window pixmaps from scene windows One of the scene redesign goals is to make wayland surface items re-usable. So we have the same rendering path for drag-and-drop icons, software cursors, and window surfaces. The biggest issue at the moment is that window pixmaps are tightly coupled with scene windows. This change de-couples window pixmaps from scene windows. In order to achieve that, some architecture changes were made. The WindowPixmap class was replaced with the SurfacePixmap class. A surface pixmap is created by a surface item. Under the hood, a SurfacePixmap will create a PlatformSurfaceTexture object, which contains all the information necessary for the renderer. The SceneOpenGLTexture class was removed. However, the GLX and the EGL on X11 backends still mess with GLTexture's internals.
2021-04-09 07:06:04 +00:00
Improve thumbnail item integration Currently, thumbnail items are rendered by kwin. This means that qtquick code cannot do things such as applying shader effects to window thumbnails or simply draw custom controls on top of thumbnails. With this change, task switchers and qml extensions will be able to place their own contents on top of thumbnails and apply custom effects to them. In order to integrate window thumbnails, a window is rendered on kwin side using its own opengl context. A fence is inserted in the command stream to ensure that the qtquick machinery doesn't start using the offscreen texture while there are still rendering commands being executed. Thumbnails are rendered into offscreen textures as we don't have full control over when qtquick windows render their contents and to work around the fact that things such as VAOs can't be shared across OpenGL contexts. WindowThumbnailItem and DesktopThumbnailItem act as texture providers.
2021-06-02 08:45:50 +00:00
virtual void paintDesktop(int desktop, int mask, const QRegion &region, ScreenPaintData &data);
scene: Compute projection matrix based on the render target rect Neither SceneQPainter nor SceneOpenGL have to compute the projection matrix by themselves. It can be done by the Scene when setting the projection matrix. The main benefit behind this change is that it reduces the amount of custom setup code around paintScreen(), which makes us one step closer to getting rid of graphics-specific paint() function and just calling paintScreen().
2022-02-15 13:10:31 +00:00
QMatrix4x4 renderTargetProjectionMatrix() const;
kwineffects: Make GLRenderTarget and GLVertexBuffer work without global coords and scale Because the GLRenderTarget and the GLVertexBuffer use the global coordinate system, they are not ergonomic in render layers. Assigning the device pixel ratio to GLRenderTarget and GLVertexBuffer is an interesting api design choice too. Scaling is a window system abstraction, which is absent in OpenGL or Vulkan. For example, it's not possible to create an OpenGL texture with a scale factor of 2. It only works with device pixels. This change makes the GLRenderTarget and the GLVertexBuffer more ergonomic for usages other than rendering the workspace by removing all the global coordinate system and scaling stuff. That's the responsibility of the users of those two classes.
2022-02-06 12:07:48 +00:00
QRect renderTargetRect() const;
void setRenderTargetRect(const QRect &rect);
qreal renderTargetScale() const;
void setRenderTargetScale(qreal scale);
QRegion mapToRenderTarget(const QRegion &region) const;
[autotests] Add a new test case which can verify the rendering of QPainter Scene Summary: The idea behind this autotest is inspired by bug 356328 which produced incorrect rendering results. Also it's inspired by openQA which performs image reference comparisons. This test case tries to go further. It creates reference images which must match the rendering result exactly. So far the test case verifies the start condition - kwin started and one frame is rendered with default cursor in the middle of the screen. And it verifies the moving of the cursor without any windows shown. Whenever the cursor moves a repaint should be triggered and the old and new area should be properly repainted. To support this the test needs some minor changes in KWin: * Scene provides a frameRendered signal - needed for waiting on frame * Scene and SceneQPainter are exported * SceneQPainter provides access to it's Backend, so that we get to the backbuffer * ScriptedEffectLoader is exported for getting a list of all scripted effects - (we don't want fade to manipulate the rendering) Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2046
2016-06-29 17:22:41 +00:00
Q_SIGNALS:
void frameRendered();
Make Q slots public in class Scene This commit just makes the slots public that are used in Scene class and its inheriting subclasses.
2011-06-19 20:18:21 +00:00
public Q_SLOTS:
Make Scene::windowClosed() a Q_SLOT This commit just makes the declaration of windowClosed() in Class Scene be a Q_SLOT. The inheriting classes SceneOpenGL and SceneXRender are updated as well.
2011-06-21 10:30:42 +00:00
// a window has been closed
Move Scene::Window handling methods into base class The pure virtual methods windowAdded, windowClosed, windowDeleted and windowGeometryShapeChanged had identical implementations in both XRender and OpenGL scene. They were accessing the hash with Scene::Windows which is nowhere else used except for creating the stacking order in ::paint. The implementations are moved to the base class, the only Scene specific code is a pure virtual factory method to create the Scene window. This already existed in SceneOpenGL to create either a SceneOpenGL1 or 2 window. Also the hash of windows is a Scene private member now and the creation of the stacking order is provided by a method, so that the Scene sub classes do no longer need to access the stacking order at all. REVIEW: 111207
2013-06-24 07:53:11 +00:00
void windowClosed(KWin::Toplevel* c, KWin::Deleted* deleted);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
protected:
Move Scene::Window handling methods into base class The pure virtual methods windowAdded, windowClosed, windowDeleted and windowGeometryShapeChanged had identical implementations in both XRender and OpenGL scene. They were accessing the hash with Scene::Windows which is nowhere else used except for creating the stacking order in ::paint. The implementations are moved to the base class, the only Scene specific code is a pure virtual factory method to create the Scene window. This already existed in SceneOpenGL to create either a SceneOpenGL1 or 2 window. Also the hash of windows is a Scene private member now and the creation of the stacking order is provided by a method, so that the Scene sub classes do no longer need to access the stacking order at all. REVIEW: 111207
2013-06-24 07:53:11 +00:00
virtual Window *createWindow(Toplevel *toplevel) = 0;
Move direct scanout management to Compositor The responsibilities of the Scene must be reduced to painting only so we can move forward with the layer-based compositing. This change moves direct scanout logic from the opengl scene to the base scene class and the compositor. It makes the opengl scene less overloaded and allows to share direct scanout logic.
2022-02-04 17:38:58 +00:00
void createStackingOrder();
Move Scene::Window handling methods into base class The pure virtual methods windowAdded, windowClosed, windowDeleted and windowGeometryShapeChanged had identical implementations in both XRender and OpenGL scene. They were accessing the hash with Scene::Windows which is nowhere else used except for creating the stacking order in ::paint. The implementations are moved to the base class, the only Scene specific code is a pure virtual factory method to create the Scene window. This already existed in SceneOpenGL to create either a SceneOpenGL1 or 2 window. Also the hash of windows is a Scene private member now and the creation of the stacking order is provided by a method, so that the Scene sub classes do no longer need to access the stacking order at all. REVIEW: 111207
2013-06-24 07:53:11 +00:00
void clearStackingOrder();
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
// shared implementation, starts painting the screen
scene: Rework surface damage tracking It's not possible to get the surface damage before calling Scene::paint(), which is a big problem because it blocks proper surface damage and buffer damage calculation when walking render layer tree. This change reworks the scene compositing stages to allow getting the next surface damage before calling Scene::paint(). The main challenge is that the effects can expand the surface damage. We have to call prePaintWindow() and prePaintScreen() before actually starting painting. However, prePaintWindow() is called after starting rendering. This change makes Scene call prePaintWindow() and prePaintScreen() so it's possible to know the surface damage beforehand. Unfortunately, it's also a breaking change. Some fullscreen effects will have to adapt to the new Scene paint order. Paint hooks will be invoked in the following order: * prePaintScreen() once per frame * prePaintWindow() once per frame * paintScreen() can be called multiple times * paintWindow() can be called as many times as paintScreen() * postPaintWindow() once per frame * postPaintScreen() once per frame After walking the render layer tree, the Compositor will poke the render backend for the back buffer repair region and combine it with the surface damage to get the buffer damage, which can be passed to the render backend (in order to optimize performance with tiled gpus) and Scene::paint(), which will determine what parts of the scene have to repainted based on the buffer damage.
2022-02-16 17:13:57 +00:00
void paintScreen(const QRegion &region);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
friend class EffectsHandlerImpl;
// called after all effects had their paintScreen() called
scene: Pass non-trivial classes by const& Summary: This will save the copy of some objects, especially PaintData classes that are not copy-on-write. It also follows the practice on other parts of the system. Test Plan: Running it right now Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D28031
2020-03-13 16:41:56 +00:00
void finalPaintScreen(int mask, const QRegion &region, ScreenPaintData& data);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
// shared implementation of painting the screen in the generic
// (unoptimized) way
scene: Rework surface damage tracking It's not possible to get the surface damage before calling Scene::paint(), which is a big problem because it blocks proper surface damage and buffer damage calculation when walking render layer tree. This change reworks the scene compositing stages to allow getting the next surface damage before calling Scene::paint(). The main challenge is that the effects can expand the surface damage. We have to call prePaintWindow() and prePaintScreen() before actually starting painting. However, prePaintWindow() is called after starting rendering. This change makes Scene call prePaintWindow() and prePaintScreen() so it's possible to know the surface damage beforehand. Unfortunately, it's also a breaking change. Some fullscreen effects will have to adapt to the new Scene paint order. Paint hooks will be invoked in the following order: * prePaintScreen() once per frame * prePaintWindow() once per frame * paintScreen() can be called multiple times * paintWindow() can be called as many times as paintScreen() * postPaintWindow() once per frame * postPaintScreen() once per frame After walking the render layer tree, the Compositor will poke the render backend for the back buffer repair region and combine it with the surface damage to get the buffer damage, which can be passed to the render backend (in order to optimize performance with tiled gpus) and Scene::paint(), which will determine what parts of the scene have to repainted based on the buffer damage.
2022-02-16 17:13:57 +00:00
void preparePaintGenericScreen();
scene: Pass non-trivial classes by const& Summary: This will save the copy of some objects, especially PaintData classes that are not copy-on-write. It also follows the practice on other parts of the system. Test Plan: Running it right now Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D28031
2020-03-13 16:41:56 +00:00
virtual void paintGenericScreen(int mask, const ScreenPaintData &data);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
// shared implementation of painting the screen in an optimized way
scene: Rework surface damage tracking It's not possible to get the surface damage before calling Scene::paint(), which is a big problem because it blocks proper surface damage and buffer damage calculation when walking render layer tree. This change reworks the scene compositing stages to allow getting the next surface damage before calling Scene::paint(). The main challenge is that the effects can expand the surface damage. We have to call prePaintWindow() and prePaintScreen() before actually starting painting. However, prePaintWindow() is called after starting rendering. This change makes Scene call prePaintWindow() and prePaintScreen() so it's possible to know the surface damage beforehand. Unfortunately, it's also a breaking change. Some fullscreen effects will have to adapt to the new Scene paint order. Paint hooks will be invoked in the following order: * prePaintScreen() once per frame * prePaintWindow() once per frame * paintScreen() can be called multiple times * paintWindow() can be called as many times as paintScreen() * postPaintWindow() once per frame * postPaintScreen() once per frame After walking the render layer tree, the Compositor will poke the render backend for the back buffer repair region and combine it with the surface damage to get the buffer damage, which can be passed to the render backend (in order to optimize performance with tiled gpus) and Scene::paint(), which will determine what parts of the scene have to repainted based on the buffer damage.
2022-02-16 17:13:57 +00:00
void preparePaintSimpleScreen();
scene: Pass non-trivial classes by const& Summary: This will save the copy of some objects, especially PaintData classes that are not copy-on-write. It also follows the practice on other parts of the system. Test Plan: Running it right now Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D28031
2020-03-13 16:41:56 +00:00
virtual void paintSimpleScreen(int mask, const QRegion &region);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
// paint the background (not the desktop background - the whole background)
scene: Pass non-trivial classes by const& Summary: This will save the copy of some objects, especially PaintData classes that are not copy-on-write. It also follows the practice on other parts of the system. Test Plan: Running it right now Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D28031
2020-03-13 16:41:56 +00:00
virtual void paintBackground(const QRegion &region) = 0;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
// called after all effects had their paintWindow() called
scene: Pass non-trivial classes by const& Summary: This will save the copy of some objects, especially PaintData classes that are not copy-on-write. It also follows the practice on other parts of the system. Test Plan: Running it right now Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D28031
2020-03-13 16:41:56 +00:00
void finalPaintWindow(EffectWindowImpl* w, int mask, const QRegion &region, WindowPaintData& data);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
// shared implementation, starts painting the window
scene: Improve window quad management At the moment, we handle window quads inefficiently. Window quads from all items are merged into a single list just to be broken up again. This change removes window quads from libkwineffects. This allows us to handle window quads efficiently. Furthermore, we could optimize methods such as WindowVertex::left() and so on. KWin spends reasonable amount of time in those methods when many windows have to be composited. It's a necessary prerequisite for making wl_surface painting code role agnostic.
2021-06-10 10:32:37 +00:00
virtual void paintWindow(Window* w, int mask, const QRegion &region);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
// called after all effects had their drawWindow() called
scene: Pass non-trivial classes by const& Summary: This will save the copy of some objects, especially PaintData classes that are not copy-on-write. It also follows the practice on other parts of the system. Test Plan: Running it right now Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D28031
2020-03-13 16:41:56 +00:00
virtual void finalDrawWindow(EffectWindowImpl* w, int mask, const QRegion &region, WindowPaintData& 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
Rename EffectQuickScene to OffscreenQuickScene EffectQuickScene is not used strictly by effects, aurorae decorations use it too to render window decorations. This change renames the EffectQuickView/Scene to OffscreenQuickView/Scene to clear up the naming scheme.
2021-11-19 09:19:59 +00:00
virtual void paintOffscreenQuickView(OffscreenQuickView *w) = 0;
[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
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
// saved data for 2nd pass of optimized screen painting
struct Phase2Data {
Drop Phase2Data constructors Summary: We initialize all fields of Phase2Data at once, so the constructors seem to be redundant. Reviewers: #kwin, graesslin Reviewed By: #kwin, graesslin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18207
2019-01-12 12:39:28 +00:00
Window *window = nullptr;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
QRegion region;
scene: Rename Phase2Data::clip to Phase2Data::opaque It makes code easier to understand.
2022-02-17 10:16:29 +00:00
QRegion opaque;
Drop Phase2Data constructors Summary: We initialize all fields of Phase2Data at once, so the constructors seem to be redundant. Reviewers: #kwin, graesslin Reviewed By: #kwin, graesslin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18207
2019-01-12 12:39:28 +00:00
int mask = 0;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
};
scene: Rework surface damage tracking It's not possible to get the surface damage before calling Scene::paint(), which is a big problem because it blocks proper surface damage and buffer damage calculation when walking render layer tree. This change reworks the scene compositing stages to allow getting the next surface damage before calling Scene::paint(). The main challenge is that the effects can expand the surface damage. We have to call prePaintWindow() and prePaintScreen() before actually starting painting. However, prePaintWindow() is called after starting rendering. This change makes Scene call prePaintWindow() and prePaintScreen() so it's possible to know the surface damage beforehand. Unfortunately, it's also a breaking change. Some fullscreen effects will have to adapt to the new Scene paint order. Paint hooks will be invoked in the following order: * prePaintScreen() once per frame * prePaintWindow() once per frame * paintScreen() can be called multiple times * paintWindow() can be called as many times as paintScreen() * postPaintWindow() once per frame * postPaintScreen() once per frame After walking the render layer tree, the Compositor will poke the render backend for the back buffer repair region and combine it with the surface damage to get the buffer damage, which can be passed to the render backend (in order to optimize performance with tiled gpus) and Scene::paint(), which will determine what parts of the scene have to repainted based on the buffer damage.
2022-02-16 17:13:57 +00:00
struct PaintContext {
QRegion damage;
int mask = 0;
QVector<Phase2Data> phase2Data;
};
Store repaint regions per individual screen AnimationEffect schedules repaints in postPaintWindow() and performs cleanup in preScreenPaint(). With the X11-style rendering, this doesn't have any issues, scheduled repaints will be reset during the next compositing cycle. But with per screen rendering, we might hit the following case - Paint screen 0 - Reset scheduled repaints - AnimationEffect::prePaintScreen(): update the timeline - AnimationEffect::postPaintScreen(): schedule a repaint - Paint screen 1 - Reset scheduled repaints - AnimationEffect::prePaintScreen(): destroy the animation - AnimationEffect::postPaintScreen(): no repaint is scheduled - Return to the event loop In this scenario, the repaint region scheduled by AnimationEffect will be lost when compositing is performed on screen 1. There is no any other way to fix this issue but maintain repaint regions per each individual screen if per screen rendering is enabled. BUG: 428439
2020-10-29 18:25:39 +00:00
// The screen that is being currently painted
Port screenId based rendering methods to AbstractOutput
2021-08-24 20:55:42 +00:00
AbstractOutput *painted_screen = nullptr;
Implement direct scanout for the gbm backend
2021-02-02 13:26:43 +00:00
// windows in their stacking order
QVector< Window* > stacking_order;
Adding a DesktopThumbnailItem declarative item Similar to WindowThumbnailItem for rendering a desktop thumbnail. Uses the new paintDesktop hook. FEATURE: 296067 FIXED-IN: 4.11.0 REVIEW: 104441
2012-03-29 18:17:57 +00:00
private:
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();
Introduce render layers This is the first tiny step towards the layer-based compositing in kwin. The RenderLayer represents a layer with some contents. The actual contents is represented by the RenderLayerDelegate class. Currently, the RenderLayer is just a simple class responsible for geometry, and repaints, but it will grow in the future. For example, render layers need to form a tree. The next (missing) biggest component in the layer-based compositing are output layers. When output layers are added, each render layer would have an output layer assigned to it or have its output layer inherited from the parent. The render layer tree wouldn't be affected by changes to the output layer tree so transition between software and hardware cursors can be seamless. The next big milestone will be to try to port some of existing kwin functionality to the RenderLayer, e.g. software cursor or screen edges.
2022-02-04 18:38:37 +00:00
QList<SceneDelegate *> m_delegates;
Move Scene::Window handling methods into base class The pure virtual methods windowAdded, windowClosed, windowDeleted and windowGeometryShapeChanged had identical implementations in both XRender and OpenGL scene. They were accessing the hash with Scene::Windows which is nowhere else used except for creating the stacking order in ::paint. The implementations are moved to the base class, the only Scene specific code is a pure virtual factory method to create the Scene window. This already existed in SceneOpenGL to create either a SceneOpenGL1 or 2 window. Also the hash of windows is a Scene private member now and the creation of the stacking order is provided by a method, so that the Scene sub classes do no longer need to access the stacking order at all. REVIEW: 111207
2013-06-24 07:53:11 +00:00
QHash< Toplevel*, Window* > m_windows;
Allow specifying scene geometry The main motivation behind this change is to decouple the scene a bit further from Screens, which is also obsolete.
2021-11-24 17:18:31 +00:00
QRect m_geometry;
scene: Compute projection matrix based on the render target rect Neither SceneQPainter nor SceneOpenGL have to compute the projection matrix by themselves. It can be done by the Scene when setting the projection matrix. The main benefit behind this change is that it reduces the amount of custom setup code around paintScreen(), which makes us one step closer to getting rid of graphics-specific paint() function and just calling paintScreen().
2022-02-15 13:10:31 +00:00
QMatrix4x4 m_renderTargetProjectionMatrix;
kwineffects: Make GLRenderTarget and GLVertexBuffer work without global coords and scale Because the GLRenderTarget and the GLVertexBuffer use the global coordinate system, they are not ergonomic in render layers. Assigning the device pixel ratio to GLRenderTarget and GLVertexBuffer is an interesting api design choice too. Scaling is a window system abstraction, which is absent in OpenGL or Vulkan. For example, it's not possible to create an OpenGL texture with a scale factor of 2. It only works with device pixels. This change makes the GLRenderTarget and the GLVertexBuffer more ergonomic for usages other than rendering the workspace by removing all the global coordinate system and scaling stuff. That's the responsibility of the users of those two classes.
2022-02-06 12:07:48 +00:00
QRect m_renderTargetRect;
qreal m_renderTargetScale = 1;
Implement EGL_KHR_partial_update and EGL_EXT_swap_buffers_with_damage Summary: Notify the driver about the parts of the screen that will be repainted. In some cases this can be benefitial. This is especially useful on lima and panfrost devices (e.g. pinephone, pinebook, pinebook pro). Test Plan: Tested on a pinebook pro with a late mesa version. Basically I implemented it, then it didn't work and I fixed it. Maybe next step we want to look into our damage algorithm.
2020-04-24 17:11:41 +00:00
// how many times finalPaintScreen() has been called
int m_paintScreenCount = 0;
scene: Rework surface damage tracking It's not possible to get the surface damage before calling Scene::paint(), which is a big problem because it blocks proper surface damage and buffer damage calculation when walking render layer tree. This change reworks the scene compositing stages to allow getting the next surface damage before calling Scene::paint(). The main challenge is that the effects can expand the surface damage. We have to call prePaintWindow() and prePaintScreen() before actually starting painting. However, prePaintWindow() is called after starting rendering. This change makes Scene call prePaintWindow() and prePaintScreen() so it's possible to know the surface damage beforehand. Unfortunately, it's also a breaking change. Some fullscreen effects will have to adapt to the new Scene paint order. Paint hooks will be invoked in the following order: * prePaintScreen() once per frame * prePaintWindow() once per frame * paintScreen() can be called multiple times * paintWindow() can be called as many times as paintScreen() * postPaintWindow() once per frame * postPaintScreen() once per frame After walking the render layer tree, the Compositor will poke the render backend for the back buffer repair region and combine it with the surface damage to get the buffer damage, which can be passed to the render backend (in order to optimize performance with tiled gpus) and Scene::paint(), which will determine what parts of the scene have to repainted based on the buffer damage.
2022-02-16 17:13:57 +00:00
PaintContext m_paintContext;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
};
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
// The base class for windows representations in composite backends
[scene] Make the scene window a qobject Since the scene window is not a QObject, we cannot connect toplevel's signals directly to the scene window's slots.
2020-06-10 06:13:35 +00:00
class Scene::Window : public QObject
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
[scene] Make the scene window a qobject Since the scene window is not a QObject, we cannot connect toplevel's signals directly to the scene window's slots.
2020-06-10 06:13:35 +00:00
Q_OBJECT
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
public:
[scene] Make the scene window a qobject Since the scene window is not a QObject, we cannot connect toplevel's signals directly to the scene window's slots.
2020-06-10 06:13:35 +00:00
explicit Window(Toplevel *client, QObject *parent = nullptr);
~Window() override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
// perform the actual painting of the window
scene: Pass non-trivial classes by const& Summary: This will save the copy of some objects, especially PaintData classes that are not copy-on-write. It also follows the practice on other parts of the system. Test Plan: Running it right now Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D28031
2020-03-13 16:41:56 +00:00
virtual void performPaint(int mask, const QRegion &region, const WindowPaintData &data) = 0;
KWin uses kdelibs coding style.
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
Make Scene::Window::window() and WindowPixmap::toplevel() const No need to have them not const.
2016-04-01 07:17:27 +00:00
Toplevel* window() const;
KWin uses kdelibs coding style.
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
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
};
KWin uses kdelibs coding style.
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;
Adjust scene for client-side decorated clients Summary: Currently our Scene is quite naive about geometry. It assumes that the window frame wraps the attached buffer/client. While this is true for X11 clients, such geometry model is not suitable for client-side decorated clients, in our case for xdg-shell clients that set window geometry other than the bounding rectangle of the main surface. In general, the proposed solution doesn't make any concrete assumptions about the order between frame and buffer geometry, however we may still need to reconsider the design of Scene once it starts to generate quads for sub-surfaces. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, romangg, kwin Tags: #kwin Maniphest Tasks: T10867 Differential Revision: https://phabricator.kde.org/D24462
2019-09-27 10:33:42 +00:00
QRegion decorationShape() const;
scene: Stop monitoring changes for unmapped surfaces Once the main surface has been unmapped, we are no longer interested in any changes that indicate that the window quads cache should be discarded This also fixes a bug where the scene holds a subsurface monitor object even after the associated window has been destroyed.
2020-11-03 11:18:09 +00:00
void updateToplevel(Deleted *deleted);
New class to encapsulate a Window's Pixmap The behavior for creating a pixmap for a window is moved from Toplevel into a dedicated class WindowPixmap. Scene::Window holds a reference to this class and creates a new WindowPixmap whenever the pixmap needs to be discarded. In addition it also keeps the old WindowPixmap around for the case that creating the new pixmap fails. The compositor can in that case use the previous pixmap which reduces possible flickering. Also this referencing can be used to improve transition effects like the maximize windows effect which would benefit from starting with the old pixmap. For XRender and OpenGL a dedicated sub-class of the WindowPixmap is created which provides the additional mapping to an XRender picture and OpenGL texture respectively. BUG: 319563 FIXED-IN: 4.11 REVIEW: 110577
2013-05-10 10:07:56 +00:00
void referencePreviousPixmap();
void unreferencePreviousPixmap();
scene: Introduce window items Currently, dealing with sub-surfaces is very difficult due to the scene design being heavily influenced by X11 requirements. The goal of this change is to re-work scene abstractions to make improving the wayland support easier. The Item class is based on the QQuickItem class. My hope is that one day we will be able to transition to QtQuick for painting scene, but in meanwhile it makes more sense to have a minimalistic internal item class. The WindowItem class represents a window. The SurfaceItem class represents the contents of either an X11, or a Wayland, or an internal surface. The DecorationItem and the ShadowItem class represent the server-side deco and drop-shadow, respectively. At the moment, the SurfaceItem is bound to the scene window, but the long term plan is to break that connection so we could re-use the SurfaceItem for things such as software cursors and drag-and-drop additional icons. One of the responsibilities of the Item is to schedule repaints as needed. Ideally, there shouldn't be any addRepaint() calls in the core code. The Item class schedules repaints on geometry updates. In the future, it also has to request an update if its opacity or visibility changes.
2021-02-04 09:07:20 +00:00
WindowItem *windowItem() const;
SurfaceItem *surfaceItem() const;
ShadowItem *shadowItem() const;
screencasting: Expose necessary information to implement efficient screencasting
2020-07-22 17:22:36 +00:00
scene: Introduce window items Currently, dealing with sub-surfaces is very difficult due to the scene design being heavily influenced by X11 requirements. The goal of this change is to re-work scene abstractions to make improving the wayland support easier. The Item class is based on the QQuickItem class. My hope is that one day we will be able to transition to QtQuick for painting scene, but in meanwhile it makes more sense to have a minimalistic internal item class. The WindowItem class represents a window. The SurfaceItem class represents the contents of either an X11, or a Wayland, or an internal surface. The DecorationItem and the ShadowItem class represent the server-side deco and drop-shadow, respectively. At the moment, the SurfaceItem is bound to the scene window, but the long term plan is to break that connection so we could re-use the SurfaceItem for things such as software cursors and drag-and-drop additional icons. One of the responsibilities of the Item is to schedule repaints as needed. Ideally, there shouldn't be any addRepaint() calls in the core code. The Item class schedules repaints on geometry updates. In the future, it also has to request an update if its opacity or visibility changes.
2021-02-04 09:07:20 +00:00
protected:
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Toplevel* toplevel;
private:
scene: Introduce window items Currently, dealing with sub-surfaces is very difficult due to the scene design being heavily influenced by X11 requirements. The goal of this change is to re-work scene abstractions to make improving the wayland support easier. The Item class is based on the QQuickItem class. My hope is that one day we will be able to transition to QtQuick for painting scene, but in meanwhile it makes more sense to have a minimalistic internal item class. The WindowItem class represents a window. The SurfaceItem class represents the contents of either an X11, or a Wayland, or an internal surface. The DecorationItem and the ShadowItem class represent the server-side deco and drop-shadow, respectively. At the moment, the SurfaceItem is bound to the scene window, but the long term plan is to break that connection so we could re-use the SurfaceItem for things such as software cursors and drag-and-drop additional icons. One of the responsibilities of the Item is to schedule repaints as needed. Ideally, there shouldn't be any addRepaint() calls in the core code. The Item class schedules repaints on geometry updates. In the future, it also has to request an update if its opacity or visibility changes.
2021-02-04 09:07:20 +00:00
void referencePreviousPixmap_helper(SurfaceItem *item);
void unreferencePreviousPixmap_helper(SurfaceItem *item);
void updateWindowPosition();
Store repaint regions per individual screen AnimationEffect schedules repaints in postPaintWindow() and performs cleanup in preScreenPaint(). With the X11-style rendering, this doesn't have any issues, scheduled repaints will be reset during the next compositing cycle. But with per screen rendering, we might hit the following case - Paint screen 0 - Reset scheduled repaints - AnimationEffect::prePaintScreen(): update the timeline - AnimationEffect::postPaintScreen(): schedule a repaint - Paint screen 1 - Reset scheduled repaints - AnimationEffect::prePaintScreen(): destroy the animation - AnimationEffect::postPaintScreen(): no repaint is scheduled - Return to the event loop In this scenario, the repaint region scheduled by AnimationEffect will be lost when compositing is performed on screen 1. There is no any other way to fix this issue but maintain repaint regions per each individual screen if per screen rendering is enabled. BUG: 428439
2020-10-29 18:25:39 +00:00
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
int disable_painting;
scene: Introduce window items Currently, dealing with sub-surfaces is very difficult due to the scene design being heavily influenced by X11 requirements. The goal of this change is to re-work scene abstractions to make improving the wayland support easier. The Item class is based on the QQuickItem class. My hope is that one day we will be able to transition to QtQuick for painting scene, but in meanwhile it makes more sense to have a minimalistic internal item class. The WindowItem class represents a window. The SurfaceItem class represents the contents of either an X11, or a Wayland, or an internal surface. The DecorationItem and the ShadowItem class represent the server-side deco and drop-shadow, respectively. At the moment, the SurfaceItem is bound to the scene window, but the long term plan is to break that connection so we could re-use the SurfaceItem for things such as software cursors and drag-and-drop additional icons. One of the responsibilities of the Item is to schedule repaints as needed. Ideally, there shouldn't be any addRepaint() calls in the core code. The Item class schedules repaints on geometry updates. In the future, it also has to request an update if its opacity or visibility changes.
2021-02-04 09:07:20 +00:00
QScopedPointer<WindowItem> m_windowItem;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Q_DISABLE_COPY(Window)
};
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Refactoring of EffectFrame: EffectFrame becomes an interface just like EffectsHandler and EffectWindow and a concrete EffectFrameImpl in core. Rendering of the EffectFrame is moved into the scene as Scene::EffectFrame with a concrete implementation in SceneXrender and SceneOpenGL. A factory method for an EffectFrame is added to the EffectsHandler, which is used by the effects. Next step: pass the EffectFrame through all effects, so that effects can transform, blur, invert whatever it. svn path=/trunk/KDE/kdebase/workspace/; revision=1151271
2010-07-18 16:32:37 +00:00
class Scene::EffectFrame
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
public:
EffectFrame(EffectFrameImpl* frame);
virtual ~EffectFrame();
scene: Pass non-trivial classes by const& Summary: This will save the copy of some objects, especially PaintData classes that are not copy-on-write. It also follows the practice on other parts of the system. Test Plan: Running it right now Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D28031
2020-03-13 16:41:56 +00:00
virtual void render(const QRegion &region, double opacity, double frameOpacity) = 0;
KWin uses kdelibs coding style.
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;
};
Refactoring of EffectFrame: EffectFrame becomes an interface just like EffectsHandler and EffectWindow and a concrete EffectFrameImpl in core. Rendering of the EffectFrame is moved into the scene as Scene::EffectFrame with a concrete implementation in SceneXrender and SceneOpenGL. A factory method for an EffectFrame is added to the EffectsHandler, which is used by the effects. Next step: pass the EffectFrame through all effects, so that effects can transform, blur, invert whatever it. svn path=/trunk/KDE/kdebase/workspace/; revision=1151271
2010-07-18 16:32:37 +00:00
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
inline
int Scene::Window::x() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
return toplevel->x();
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
inline
int Scene::Window::y() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
return toplevel->y();
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
inline
int Scene::Window::width() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
return toplevel->width();
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
inline
int Scene::Window::height() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
return toplevel->height();
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
inline
QRect Scene::Window::geometry() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
Rename geometry property to frameGeometry Summary: In order to properly implement xdg_surface.set_window_geometry we need two kinds of geometry - frame and buffer. The frame geometry specifies visible bounds of the client on the screen, excluding client-side drop shadows. The buffer geometry specifies rectangle on the screen that the attached buffer or x11 pixmap occupies on the screen. This change renames the geometry property to frameGeometry in order to reflect the new meaning assigned to it as well to make it easier to differentiate between frame geometry and buffer geometry in the future. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24334
2019-09-27 10:01:10 +00:00
return toplevel->frameGeometry();
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
inline
QSize Scene::Window::size() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
return toplevel->size();
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
inline
QPoint Scene::Window::pos() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
return toplevel->pos();
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
inline
QRect Scene::Window::rect() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
return toplevel->rect();
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
inline
Make Scene::Window::window() and WindowPixmap::toplevel() const No need to have them not const.
2016-04-01 07:17:27 +00:00
Toplevel* Scene::Window::window() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
return toplevel;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
} // namespace
#endif
Reference in a new issue Copy permalink