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

229 lines
7 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"
#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->client(), &AbstractClient::screenScaleChanged,
this, &DecorationRenderer::invalidate);
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()
{
addDamage(m_client->client()->rect());
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();
}
QImage DecorationRenderer::renderToImage(const QRect &geo)
{
Q_ASSERT(m_client);
auto dpr = client()->client()->screenScale();
// 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;
};
QImage image(geo.width() * dpr, geo.height() * dpr, format);
image.setDevicePixelRatio(dpr);
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);
}
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
DecorationItem::DecorationItem(KDecoration2::Decoration *decoration, Scene::Window *window, Item *parent)
: Item(window, parent)
{
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
AbstractClient *client = qobject_cast<AbstractClient *>(window->window());
m_renderer.reset(Compositor::self()->scene()->createDecorationRenderer(client->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
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(client, &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);
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(client, &Toplevel::screenScaleChanged,
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::discardQuads);
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);
// If the decoration is about to be destroyed, render the decoration for the last time.
connect(client, &Toplevel::markedAsZombie, this, &DecorationItem::preprocess);
setSize(client->size());
}
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
}
void DecorationItem::handleFrameGeometryChanged()
{
setSize(window()->size());
}
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
{
const Toplevel *toplevel = window()->window();
if (toplevel->frameMargins().isNull()) {
return WindowQuadList();
}
QRect rects[4];
if (const AbstractClient *client = qobject_cast<const AbstractClient *>(toplevel)) {
client->layoutDecorationRects(rects[0], rects[1], rects[2], rects[3]);
} else if (const Deleted *deleted = qobject_cast<const Deleted *>(toplevel)) {
deleted->layoutDecorationRects(rects[0], rects[1], rects[2], rects[3]);
}
const qreal textureScale = toplevel->screenScale();
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
};
const QRegion shape = QRegion(toplevel->rect()) - toplevel->transparentRect();
WindowQuadList list;
list.reserve(shape.rectCount());
for (int i = 0; i < 4; i++) {
const QRegion intersectedRegion = (shape & rects[i]);
for (const QRect &r : intersectedRegion) {
if (!r.isValid()) {
continue;
}
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;
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
WindowQuad 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
kwineffects: Remove WindowQuad::uvAxisSwapped Since makeSubQuad() uses bilinear interpolation, the flag to indicate whether UV-coordinates are swapped is redundant.
2021-06-26 07:36:33 +00:00
if (orientations[i] == Qt::Vertical) {
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
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);
}
}
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