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

269 lines
7.6 KiB
C++
Raw Normal View History

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
/*
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
SPDX-FileCopyrightText: 2014 Martin Gräßlin <mgraesslin@kde.org>
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
SPDX-FileCopyrightText: 2021 Vlad Zahorodnii <vlad.zahorodnii@kde.org>
SPDX-License-Identifier: GPL-2.0-or-later
*/
#include "decorationitem.h"
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
#include "abstract_client.h"
Kill Toplevel::screenScale() Tracking AbstractOutput properties in Toplevel is not extensible. Since DecorationItem is the only one who needs Toplevel::screenScale(), make it track the output device pixel ratio.
2021-11-26 09:18:19 +00:00
#include "abstract_output.h"
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
#include "composite.h"
#include "decorations/decoratedclient.h"
Refactor window quad handling The scene items depend on the scene windows for caching window quads. The goal of this change is to move window quads management to item. Merging window quads in one list and then splitting them is inefficient, it will be highly desirable if window quads are removed from the public api so we can optimize window quad management. With this change, the window quad type becomes irrelevant to render backends for the most part. Note that the Xrender backend is a bit nitpicky about window quads, so the shadow item doesn't create generic "WindowQuadShadow" quads anymore.
2021-05-21 10:51:23 +00:00
#include "deleted.h"
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
#include "scene.h"
#include "utils.h"
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
#include <KDecoration2/Decoration>
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
#include <KDecoration2/DecoratedClient>
#include <QPainter>
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
namespace KWin
{
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
DecorationRenderer::DecorationRenderer(Decoration::DecoratedClientImpl *client)
: m_client(client)
, m_imageSizesDirty(true)
{
connect(client->decoration(), &KDecoration2::Decoration::damaged,
this, &DecorationRenderer::addDamage);
connect(client->decoration(), &KDecoration2::Decoration::bordersChanged,
this, &DecorationRenderer::invalidate);
connect(client->decoratedClient(), &KDecoration2::DecoratedClient::sizeChanged,
this, &DecorationRenderer::invalidate);
invalidate();
}
Decoration::DecoratedClientImpl *DecorationRenderer::client() const
{
return m_client;
}
void DecorationRenderer::invalidate()
{
DecorationItem: Prevent crash We are calling a QPointer without checking it first.
2021-11-05 22:54:48 +00:00
if (m_client) {
addDamage(m_client->client()->rect());
}
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
m_imageSizesDirty = true;
}
QRegion DecorationRenderer::damage() const
{
return m_damage;
}
void DecorationRenderer::addDamage(const QRegion &region)
{
m_damage += region;
Run clazy with qt-keywords fixit In C++20, there will be emit() class member, which can conflict with the emit keyword. Given that, there are plans to enable QT_NO_KEYWORDS by default in the future. See also https://lists.qt-project.org/pipermail/development/2020-February/038812.html
2021-06-08 07:02:14 +00:00
Q_EMIT damaged(region);
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
}
void DecorationRenderer::resetDamage()
{
m_damage = QRegion();
}
Kill Toplevel::screenScale() Tracking AbstractOutput properties in Toplevel is not extensible. Since DecorationItem is the only one who needs Toplevel::screenScale(), make it track the output device pixel ratio.
2021-11-26 09:18:19 +00:00
qreal DecorationRenderer::devicePixelRatio() const
{
return m_devicePixelRatio;
}
void DecorationRenderer::setDevicePixelRatio(qreal dpr)
{
if (m_devicePixelRatio != dpr) {
m_devicePixelRatio = dpr;
invalidate();
}
}
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
QImage DecorationRenderer::renderToImage(const QRect &geo)
{
Q_ASSERT(m_client);
// Guess the pixel format of the X pixmap into which the QImage will be copied.
QImage::Format format;
const int depth = client()->client()->depth();
switch (depth) {
case 30:
format = QImage::Format_A2RGB30_Premultiplied;
break;
case 24:
case 32:
format = QImage::Format_ARGB32_Premultiplied;
break;
default:
qCCritical(KWIN_CORE) << "Unsupported client depth" << depth;
format = QImage::Format_ARGB32_Premultiplied;
break;
};
Kill Toplevel::screenScale() Tracking AbstractOutput properties in Toplevel is not extensible. Since DecorationItem is the only one who needs Toplevel::screenScale(), make it track the output device pixel ratio.
2021-11-26 09:18:19 +00:00
QImage image(geo.width() * m_devicePixelRatio, geo.height() * m_devicePixelRatio, format);
image.setDevicePixelRatio(m_devicePixelRatio);
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
image.fill(Qt::transparent);
QPainter p(&image);
p.setRenderHint(QPainter::Antialiasing);
p.setWindow(QRect(geo.topLeft(), geo.size() * qPainterEffectiveDevicePixelRatio(&p)));
p.setClipRect(geo);
renderToPainter(&p, geo);
return image;
}
void DecorationRenderer::renderToPainter(QPainter *painter, const QRect &rect)
{
client()->decoration()->paint(painter, rect);
}
Remove scene window traces in scene items This further decouples scene items from scene windows. The SurfaceItem still needs to access the underlying window, I would like to re-iterate over that later. With this change, it will be possible to introduce WindowItem factory function in the Toplevel class.
2021-08-12 09:07:38 +00:00
DecorationItem::DecorationItem(KDecoration2::Decoration *decoration, AbstractClient *window, Item *parent)
: Item(parent)
, m_window(window)
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
{
Remove scene window traces in scene items This further decouples scene items from scene windows. The SurfaceItem still needs to access the underlying window, I would like to re-iterate over that later. With this change, it will be possible to introduce WindowItem factory function in the Toplevel class.
2021-08-12 09:07:38 +00:00
m_renderer.reset(Compositor::self()->scene()->createDecorationRenderer(window->decoratedClient()));
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
Remove scene window traces in scene items This further decouples scene items from scene windows. The SurfaceItem still needs to access the underlying window, I would like to re-iterate over that later. With this change, it will be possible to introduce WindowItem factory function in the Toplevel class.
2021-08-12 09:07:38 +00:00
connect(window, &Toplevel::frameGeometryChanged,
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
this, &DecorationItem::handleFrameGeometryChanged);
Remove scene window traces in scene items This further decouples scene items from scene windows. The SurfaceItem still needs to access the underlying window, I would like to re-iterate over that later. With this change, it will be possible to introduce WindowItem factory function in the Toplevel class.
2021-08-12 09:07:38 +00:00
connect(window, &Toplevel::windowClosed,
this, &DecorationItem::handleWindowClosed);
Kill Toplevel::screenScale() Tracking AbstractOutput properties in Toplevel is not extensible. Since DecorationItem is the only one who needs Toplevel::screenScale(), make it track the output device pixel ratio.
2021-11-26 09:18:19 +00:00
connect(window, &Toplevel::screenChanged,
this, &DecorationItem::handleOutputChanged);
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
connect(decoration, &KDecoration2::Decoration::bordersChanged,
this, &DecorationItem::discardQuads);
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
connect(renderer(), &DecorationRenderer::damaged,
this, &DecorationItem::scheduleRepaint);
Remove scene window traces in scene items This further decouples scene items from scene windows. The SurfaceItem still needs to access the underlying window, I would like to re-iterate over that later. With this change, it will be possible to introduce WindowItem factory function in the Toplevel class.
2021-08-12 09:07:38 +00:00
setSize(window->size());
Kill Toplevel::screenScale() Tracking AbstractOutput properties in Toplevel is not extensible. Since DecorationItem is the only one who needs Toplevel::screenScale(), make it track the output device pixel ratio.
2021-11-26 09:18:19 +00:00
handleOutputChanged();
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
}
void DecorationItem::preprocess()
{
const QRegion damage = m_renderer->damage();
if (!damage.isEmpty()) {
m_renderer->render(damage);
m_renderer->resetDamage();
}
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
}
Kill Toplevel::screenScale() Tracking AbstractOutput properties in Toplevel is not extensible. Since DecorationItem is the only one who needs Toplevel::screenScale(), make it track the output device pixel ratio.
2021-11-26 09:18:19 +00:00
void DecorationItem::handleOutputChanged()
{
if (m_output) {
disconnect(m_output, &AbstractOutput::scaleChanged, this, &DecorationItem::handleOutputScaleChanged);
}
m_output = m_window->output();
if (m_output) {
handleOutputScaleChanged();
connect(m_output, &AbstractOutput::scaleChanged, this, &DecorationItem::handleOutputScaleChanged);
}
}
void DecorationItem::handleOutputScaleChanged()
{
const qreal dpr = m_output->scale();
if (m_renderer->devicePixelRatio() != dpr) {
m_renderer->setDevicePixelRatio(dpr);
discardQuads();
}
}
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 DecorationItem::handleFrameGeometryChanged()
{
Remove scene window traces in scene items This further decouples scene items from scene windows. The SurfaceItem still needs to access the underlying window, I would like to re-iterate over that later. With this change, it will be possible to introduce WindowItem factory function in the Toplevel class.
2021-08-12 09:07:38 +00:00
setSize(m_window->size());
}
void DecorationItem::handleWindowClosed(Toplevel *original, Deleted *deleted)
{
Q_UNUSED(original)
m_window = deleted;
// If the decoration is about to be destroyed, render the decoration for the last time.
preprocess();
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
}
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
DecorationRenderer *DecorationItem::renderer() const
{
return m_renderer.data();
}
Refactor window quad handling The scene items depend on the scene windows for caching window quads. The goal of this change is to move window quads management to item. Merging window quads in one list and then splitting them is inefficient, it will be highly desirable if window quads are removed from the public api so we can optimize window quad management. With this change, the window quad type becomes irrelevant to render backends for the most part. Note that the Xrender backend is a bit nitpicky about window quads, so the shadow item doesn't create generic "WindowQuadShadow" quads anymore.
2021-05-21 10:51:23 +00:00
WindowQuadList DecorationItem::buildQuads() const
{
Remove scene window traces in scene items This further decouples scene items from scene windows. The SurfaceItem still needs to access the underlying window, I would like to re-iterate over that later. With this change, it will be possible to introduce WindowItem factory function in the Toplevel class.
2021-08-12 09:07:38 +00:00
if (m_window->frameMargins().isNull()) {
Refactor window quad handling The scene items depend on the scene windows for caching window quads. The goal of this change is to move window quads management to item. Merging window quads in one list and then splitting them is inefficient, it will be highly desirable if window quads are removed from the public api so we can optimize window quad management. With this change, the window quad type becomes irrelevant to render backends for the most part. Note that the Xrender backend is a bit nitpicky about window quads, so the shadow item doesn't create generic "WindowQuadShadow" quads anymore.
2021-05-21 10:51:23 +00:00
return WindowQuadList();
}
QRect rects[4];
Remove scene window traces in scene items This further decouples scene items from scene windows. The SurfaceItem still needs to access the underlying window, I would like to re-iterate over that later. With this change, it will be possible to introduce WindowItem factory function in the Toplevel class.
2021-08-12 09:07:38 +00:00
if (const AbstractClient *client = qobject_cast<const AbstractClient *>(m_window)) {
Refactor window quad handling The scene items depend on the scene windows for caching window quads. The goal of this change is to move window quads management to item. Merging window quads in one list and then splitting them is inefficient, it will be highly desirable if window quads are removed from the public api so we can optimize window quad management. With this change, the window quad type becomes irrelevant to render backends for the most part. Note that the Xrender backend is a bit nitpicky about window quads, so the shadow item doesn't create generic "WindowQuadShadow" quads anymore.
2021-05-21 10:51:23 +00:00
client->layoutDecorationRects(rects[0], rects[1], rects[2], rects[3]);
Remove scene window traces in scene items This further decouples scene items from scene windows. The SurfaceItem still needs to access the underlying window, I would like to re-iterate over that later. With this change, it will be possible to introduce WindowItem factory function in the Toplevel class.
2021-08-12 09:07:38 +00:00
} else if (const Deleted *deleted = qobject_cast<const Deleted *>(m_window)) {
Refactor window quad handling The scene items depend on the scene windows for caching window quads. The goal of this change is to move window quads management to item. Merging window quads in one list and then splitting them is inefficient, it will be highly desirable if window quads are removed from the public api so we can optimize window quad management. With this change, the window quad type becomes irrelevant to render backends for the most part. Note that the Xrender backend is a bit nitpicky about window quads, so the shadow item doesn't create generic "WindowQuadShadow" quads anymore.
2021-05-21 10:51:23 +00:00
deleted->layoutDecorationRects(rects[0], rects[1], rects[2], rects[3]);
}
Kill Toplevel::screenScale() Tracking AbstractOutput properties in Toplevel is not extensible. Since DecorationItem is the only one who needs Toplevel::screenScale(), make it track the output device pixel ratio.
2021-11-26 09:18:19 +00:00
const qreal textureScale = m_renderer->devicePixelRatio();
Refactor window quad handling The scene items depend on the scene windows for caching window quads. The goal of this change is to move window quads management to item. Merging window quads in one list and then splitting them is inefficient, it will be highly desirable if window quads are removed from the public api so we can optimize window quad management. With this change, the window quad type becomes irrelevant to render backends for the most part. Note that the Xrender backend is a bit nitpicky about window quads, so the shadow item doesn't create generic "WindowQuadShadow" quads anymore.
2021-05-21 10:51:23 +00:00
const int padding = 1;
const QPoint topSpritePosition(padding, padding);
const QPoint bottomSpritePosition(padding, topSpritePosition.y() + rects[1].height() + 2 * padding);
const QPoint leftSpritePosition(bottomSpritePosition.y() + rects[3].height() + 2 * padding, padding);
const QPoint rightSpritePosition(leftSpritePosition.x() + rects[0].width() + 2 * padding, padding);
const QPoint offsets[4] = {
QPoint(-rects[0].x(), -rects[0].y()) + leftSpritePosition,
QPoint(-rects[1].x(), -rects[1].y()) + topSpritePosition,
QPoint(-rects[2].x(), -rects[2].y()) + rightSpritePosition,
QPoint(-rects[3].x(), -rects[3].y()) + bottomSpritePosition,
};
const Qt::Orientation orientations[4] = {
Qt::Vertical, // Left
Qt::Horizontal, // Top
Qt::Vertical, // Right
Qt::Horizontal, // Bottom
};
WindowQuadList list;
x11: Drop support for _NET_WM_FRAME_OVERLAP The main idea behind _NET_WM_FRAME_OVERLAP is to extend the borders of the server-side decoration so the application can draw on top of it. It was inspired by similar feature in Windows. However, _NET_WM_FRAME_OVERLAP is basically unused. Neither GTK nor Qt support it and I have never seen any application that uses it. At the moment, kwin is the only compositing window manager that supports _NET_WM_FRAME_OVERLAP. Neither mutter nor compiz nor compton and so on support it. Since _NET_WM_FRAME_OVERLAP is practically unused, there's no point for keeping supporting it. This change shouldn't affect any existing app as _NET_WM_FRAME_OVERLAP atom is not listed in _NET_SUPPORTED.
2021-08-12 11:06:17 +00:00
list.reserve(4);
for (int i = 0; i < 4; ++i) {
const QRect &r = rects[i];
if (!r.isValid()) {
continue;
Refactor window quad handling The scene items depend on the scene windows for caching window quads. The goal of this change is to move window quads management to item. Merging window quads in one list and then splitting them is inefficient, it will be highly desirable if window quads are removed from the public api so we can optimize window quad management. With this change, the window quad type becomes irrelevant to render backends for the most part. Note that the Xrender backend is a bit nitpicky about window quads, so the shadow item doesn't create generic "WindowQuadShadow" quads anymore.
2021-05-21 10:51:23 +00:00
}
x11: Drop support for _NET_WM_FRAME_OVERLAP The main idea behind _NET_WM_FRAME_OVERLAP is to extend the borders of the server-side decoration so the application can draw on top of it. It was inspired by similar feature in Windows. However, _NET_WM_FRAME_OVERLAP is basically unused. Neither GTK nor Qt support it and I have never seen any application that uses it. At the moment, kwin is the only compositing window manager that supports _NET_WM_FRAME_OVERLAP. Neither mutter nor compiz nor compton and so on support it. Since _NET_WM_FRAME_OVERLAP is practically unused, there's no point for keeping supporting it. This change shouldn't affect any existing app as _NET_WM_FRAME_OVERLAP atom is not listed in _NET_SUPPORTED.
2021-08-12 11:06:17 +00:00
const int x0 = r.x();
const int y0 = r.y();
const int x1 = r.x() + r.width();
const int y1 = r.y() + r.height();
const int u0 = (x0 + offsets[i].x()) * textureScale;
const int v0 = (y0 + offsets[i].y()) * textureScale;
const int u1 = (x1 + offsets[i].x()) * textureScale;
const int v1 = (y1 + offsets[i].y()) * textureScale;
WindowQuad quad;
if (orientations[i] == Qt::Vertical) {
quad[0] = WindowVertex(x0, y0, v0, u0); // Top-left
quad[1] = WindowVertex(x1, y0, v0, u1); // Top-right
quad[2] = WindowVertex(x1, y1, v1, u1); // Bottom-right
quad[3] = WindowVertex(x0, y1, v1, u0); // Bottom-left
} else {
quad[0] = WindowVertex(x0, y0, u0, v0); // Top-left
quad[1] = WindowVertex(x1, y0, u1, v0); // Top-right
quad[2] = WindowVertex(x1, y1, u1, v1); // Bottom-right
quad[3] = WindowVertex(x0, y1, u0, v1); // Bottom-left
}
list.append(quad);
Refactor window quad handling The scene items depend on the scene windows for caching window quads. The goal of this change is to move window quads management to item. Merging window quads in one list and then splitting them is inefficient, it will be highly desirable if window quads are removed from the public api so we can optimize window quad management. With this change, the window quad type becomes irrelevant to render backends for the most part. Note that the Xrender backend is a bit nitpicky about window quads, so the shadow item doesn't create generic "WindowQuadShadow" quads anymore.
2021-05-21 10:51:23 +00:00
}
return list;
}
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
} // namespace KWin
Reference in a new issue Copy permalink