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

88 lines
2.1 KiB
C
Raw Normal View History

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
/********************************************************************
KWin - the KDE window manager
This file is part of the KDE project.
Copyright (C) 2014 Martin Gräßlin <mgraesslin@kde.org>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*********************************************************************/
#ifndef KWIN_DECORATION_RENDERER_H
#define KWIN_DECORATION_RENDERER_H
#include <QObject>
#include <QRegion>
Move SceneXRender into a plugin Summary: First step for loading the compositor Scenes through plugins. The general idea is that we currently needlessly pull in all the Scenes although only one will be used. E.g. on X11 we pull in QPainter, although they are not compatible. On Wayland we pull in XRender although they are not compatible. Furthermore our current Scene creation strategy is not really fault tolerant and can create situations where we don't get a compositor. E.g on fbdev backend the default settings won't work as it does not support OpenGL. Long term I want to tackle those conceptional problems together: we try to load all plugins supported by the current platform till we have a scene which works. Thus on Wayland we don't end up in a situation where we don't have a working compositor because the configuration is bad. To make this possible the switch statement in the Scene needs to go and needs to be replaced by a for loop iterating over all the available scenes on the platform. If we go there it makes sense to replace it directly with a plugin based approach. So this is a change which tackles the problem by first introducing the plugin loading. The xrender based scene (as it's the most simple one) is moved into a plugin. It is first tried to find a scene plugin and only if there is none the existing code is used. Test Plan: Tested all scenes Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7232
2017-08-10 16:13:42 +00:00
#include <kwin_export.h>
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 KWin
{
Pass Decoration::Renderer to Deleted and use it in the Scenes The Renderer gets reparented to the Deleted. While passing it to the Deleted the Scene's implementation can ensure that the buffers are up to date. After passing to Deleted it's no longer allowed to call the render method.
2014-07-23 07:20:28 +00:00
class Deleted;
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;
Move SceneXRender into a plugin Summary: First step for loading the compositor Scenes through plugins. The general idea is that we currently needlessly pull in all the Scenes although only one will be used. E.g. on X11 we pull in QPainter, although they are not compatible. On Wayland we pull in XRender although they are not compatible. Furthermore our current Scene creation strategy is not really fault tolerant and can create situations where we don't get a compositor. E.g on fbdev backend the default settings won't work as it does not support OpenGL. Long term I want to tackle those conceptional problems together: we try to load all plugins supported by the current platform till we have a scene which works. Thus on Wayland we don't end up in a situation where we don't have a working compositor because the configuration is bad. To make this possible the switch statement in the Scene needs to go and needs to be replaced by a for loop iterating over all the available scenes on the platform. If we go there it makes sense to replace it directly with a plugin based approach. So this is a change which tackles the problem by first introducing the plugin loading. The xrender based scene (as it's the most simple one) is moved into a plugin. It is first tried to find a scene plugin and only if there is none the existing code is used. Test Plan: Tested all scenes Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7232
2017-08-10 16:13:42 +00:00
class KWIN_EXPORT Renderer : public QObject
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
{
Q_OBJECT
public:
Run clang-tidy with modernize-use-override check Summary: Currently code base of kwin can be viewed as two pieces. One is very ancient, and the other one is more modern, which uses new C++ features. The main problem with the ancient code is that it was written before C++11 era. So, no override or final keywords, lambdas, etc. Quite recently, KDE compiler settings were changed to show a warning if a virtual method has missing override keyword. As you might have already guessed, this fired back at us because of that ancient code. We had about 500 new compiler warnings. A "solution" was proposed to that problem - disable -Wno-suggest-override and the other similar warning for clang. It's hard to call a solution because those warnings are disabled not only for the old code, but also for new. This is not what we want! The main argument for not actually fixing the problem was that git history will be screwed as well because of human factor. While good git history is a very important thing, we should not go crazy about it and block every change that somehow alters git history. git blame allows to specify starting revision for a reason. The other argument (human factor) can be easily solved by using tools such as clang-tidy. clang-tidy is a clang-based linter for C++. It can be used for various things, e.g. fixing coding style(e.g. add missing braces to if statements, readability-braces-around-statements check), or in our case add missing override keywords. Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, apol, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 16:52:26 +00:00
~Renderer() override;
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
void schedule(const QRect &rect);
Pass Decoration::Renderer to Deleted and use it in the Scenes The Renderer gets reparented to the Deleted. While passing it to the Deleted the Scene's implementation can ensure that the buffers are up to date. After passing to Deleted it's no longer allowed to call the render method.
2014-07-23 07:20:28 +00:00
/**
* Reparents this Renderer to the @p deleted.
* After this call the Renderer is no longer able to render
* anything, client() returns a 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
*/
Pass Decoration::Renderer to Deleted and use it in the Scenes The Renderer gets reparented to the Deleted. While passing it to the Deleted the Scene's implementation can ensure that the buffers are up to date. After passing to Deleted it's no longer allowed to call the render method.
2014-07-23 07:20:28 +00:00
virtual void reparent(Deleted *deleted);
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
Q_SIGNALS:
void renderScheduled(const QRect &geo);
protected:
explicit Renderer(DecoratedClientImpl *client);
/**
* @returns the scheduled paint region and resets
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
*/
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
QRegion getScheduled();
virtual void render() = 0;
DecoratedClientImpl *client() {
return m_client;
}
bool areImageSizesDirty() const {
return m_imageSizesDirty;
}
void resetImageSizesDirty() {
m_imageSizesDirty = false;
}
QImage renderToImage(const QRect &geo);
[scene] Fix decoration texture bleeding Summary: Quite long time ago, window decorations were painted on real X11 windows. The nicest thing about that approach is that we get both contents of the client and the frame window at the same time. However, somewhere around KDE 4.2 - 4.3 times, decoration rendering architecture had been changed to what we have now. I've mentioned the previous decoration rendering design because it didn't have a problem that the new design has, namely the texture bleeding issue. In the name of better performance, opengl scene puts all decoration parts to an atlas. This is totally reasonable, however we must be super cautious about things such as the GL_LINEAR filter. The GL_LINEAR filter may need to sample a couple of neighboring texels in order to produce the final texel value. However, since all decoration parts now live in a single texture, we have to make sure that we don't sample texels that belong to another decoration part. This patch fixes the texture bleeding problem by padding each individual decoration part in the atlas. There is another solution for this problem though. We could render a window into an offscreen texture and then map that texture on the transformed window geometry. This would work well and we definitely need an offscreen rendering path in the opengl scene, however it's not feasible at the moment since we need to break the window quads API. Also, it would be great to have as less as possible stuff going on between invocation of Scene::Window::performPaint() and getting the corresponding pixel data on the screen. There is a good chance that the new padding stuff may make you vomit. If it does so, I'm all ears for the suggestions how to make the code more nicer. BUG: 257566 BUG: 360549 CCBUG: 412573 FIXED-IN: 5.18.0 Reviewers: #kwin Subscribers: fredrik, kwin, fvogt Tags: #kwin Differential Revision: https://phabricator.kde.org/D25611
2019-11-28 12:00:58 +00:00
void renderToPainter(QPainter *painter, const QRect &rect);
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
private:
DecoratedClientImpl *m_client;
QRegion m_scheduled;
bool m_imageSizesDirty;
};
}
}
#endif
Reference in a new issue Copy permalink