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

67 lines
1.6 KiB
C++
Raw Normal View History

scene: Introduce cursor item and scene The cursor scene contains the contents of the cursor. It contains a CursorItem. The CursorItem either creates a SurfaceItem or an ImageItem based on the currently attached CursorSource. The cursor item is rendered by the cursor scene. For now, wherever the cursor must be rendered, a dummy scene delegate is constructed. It's not nice but it's a pretty cheap operation. There's a lot of potential for clean up by moving cursor layer handling from output backends to compositor. The main reason why there are no persistent scene views is that it's just easier than tracking when they are actually used, e.g. after switching between hw and sw cursor. The software cursor fallback is a bit tricky case. It made to work by constructing a scratch fbo. The cursor scene is rendered in the scratch fbo, which is then rendered on the screen. Similar to the case above, there's space for improvements, but I don't think it has to block the effort for reusing Items to render the cursor.
2022-12-19 08:45:29 +00:00
/*
SPDX-FileCopyrightText: 2022 Vlad Zahorodnii <vlad.zahorodnii@kde.org>
SPDX-License-Identifier: GPL-2.0-or-later
*/
#include "scene/cursoritem.h"
#include "cursor.h"
#include "cursorsource.h"
Move WindowVertex,WindowQuad,RenderGeometry out of effects.h These are core scene abstractions and don't belong in effects.h.
2023-11-20 10:43:05 +00:00
#include "effect/effect.h"
scene: Introduce cursor item and scene The cursor scene contains the contents of the cursor. It contains a CursorItem. The CursorItem either creates a SurfaceItem or an ImageItem based on the currently attached CursorSource. The cursor item is rendered by the cursor scene. For now, wherever the cursor must be rendered, a dummy scene delegate is constructed. It's not nice but it's a pretty cheap operation. There's a lot of potential for clean up by moving cursor layer handling from output backends to compositor. The main reason why there are no persistent scene views is that it's just easier than tracking when they are actually used, e.g. after switching between hw and sw cursor. The software cursor fallback is a bit tricky case. It made to work by constructing a scratch fbo. The cursor scene is rendered in the scratch fbo, which is then rendered on the screen. Similar to the case above, there's space for improvements, but I don't think it has to block the effort for reusing Items to render the cursor.
2022-12-19 08:45:29 +00:00
#include "scene/imageitem.h"
#include "scene/itemrenderer.h"
#include "scene/scene.h"
#include "scene/surfaceitem_wayland.h"
namespace KWin
{
CursorItem::CursorItem(Scene *scene, Item *parent)
: Item(scene, parent)
{
refresh();
connect(Cursors::self(), &Cursors::currentCursorChanged, this, &CursorItem::refresh);
}
CursorItem::~CursorItem()
{
}
void CursorItem::refresh()
{
const CursorSource *source = Cursors::self()->currentCursor()->source();
if (auto surfaceSource = qobject_cast<const SurfaceCursorSource *>(source)) {
Revert "scene: Avoid creating SurfaceItem for Xwayland's cursor surfaces" This reverts commit b549776b68d8ca926ae99a1104c48804294e310d.
2023-04-06 12:06:48 +00:00
setSurface(surfaceSource->surface());
scene: Introduce cursor item and scene The cursor scene contains the contents of the cursor. It contains a CursorItem. The CursorItem either creates a SurfaceItem or an ImageItem based on the currently attached CursorSource. The cursor item is rendered by the cursor scene. For now, wherever the cursor must be rendered, a dummy scene delegate is constructed. It's not nice but it's a pretty cheap operation. There's a lot of potential for clean up by moving cursor layer handling from output backends to compositor. The main reason why there are no persistent scene views is that it's just easier than tracking when they are actually used, e.g. after switching between hw and sw cursor. The software cursor fallback is a bit tricky case. It made to work by constructing a scratch fbo. The cursor scene is rendered in the scratch fbo, which is then rendered on the screen. Similar to the case above, there's space for improvements, but I don't think it has to block the effort for reusing Items to render the cursor.
2022-12-19 08:45:29 +00:00
} else if (auto shapeSource = qobject_cast<const ShapeCursorSource *>(source)) {
setImage(shapeSource->image());
}
}
wayland: Integrate KWaylandServer classes into KWin namespace
2023-09-13 17:59:29 +00:00
void CursorItem::setSurface(SurfaceInterface *surface)
scene: Introduce cursor item and scene The cursor scene contains the contents of the cursor. It contains a CursorItem. The CursorItem either creates a SurfaceItem or an ImageItem based on the currently attached CursorSource. The cursor item is rendered by the cursor scene. For now, wherever the cursor must be rendered, a dummy scene delegate is constructed. It's not nice but it's a pretty cheap operation. There's a lot of potential for clean up by moving cursor layer handling from output backends to compositor. The main reason why there are no persistent scene views is that it's just easier than tracking when they are actually used, e.g. after switching between hw and sw cursor. The software cursor fallback is a bit tricky case. It made to work by constructing a scratch fbo. The cursor scene is rendered in the scratch fbo, which is then rendered on the screen. Similar to the case above, there's space for improvements, but I don't think it has to block the effort for reusing Items to render the cursor.
2022-12-19 08:45:29 +00:00
{
m_imageItem.reset();
if (!m_surfaceItem || m_surfaceItem->surface() != surface) {
if (surface) {
m_surfaceItem = std::make_unique<SurfaceItemWayland>(surface, scene(), this);
} else {
m_surfaceItem.reset();
}
}
}
void CursorItem::setImage(const QImage &image)
{
m_surfaceItem.reset();
if (!m_imageItem) {
scene: port away from manual memory management
2023-08-10 16:31:43 +00:00
m_imageItem = scene()->renderer()->createImageItem(scene(), this);
scene: Introduce cursor item and scene The cursor scene contains the contents of the cursor. It contains a CursorItem. The CursorItem either creates a SurfaceItem or an ImageItem based on the currently attached CursorSource. The cursor item is rendered by the cursor scene. For now, wherever the cursor must be rendered, a dummy scene delegate is constructed. It's not nice but it's a pretty cheap operation. There's a lot of potential for clean up by moving cursor layer handling from output backends to compositor. The main reason why there are no persistent scene views is that it's just easier than tracking when they are actually used, e.g. after switching between hw and sw cursor. The software cursor fallback is a bit tricky case. It made to work by constructing a scratch fbo. The cursor scene is rendered in the scratch fbo, which is then rendered on the screen. Similar to the case above, there's space for improvements, but I don't think it has to block the effort for reusing Items to render the cursor.
2022-12-19 08:45:29 +00:00
}
m_imageItem->setImage(image);
m_imageItem->setSize(image.size() / image.devicePixelRatio());
}
} // namespace KWin
Add explicit moc includes to sources for moc-covered headers * speeds up incremental builds as changes to a header will not always need the full mocs_compilation.cpp for all the target's headers rebuild, while having a moc file sourced into a source file only adds minor extra costs, due to small own code and the used headers usually already covered by the source file, being for the same class/struct * seems to not slow down clean builds, due to empty mocs_compilation.cpp resulting in those quickly processed, while the minor extra cost of the sourced moc files does not outweigh that in summary. Measured times actually improved by some percent points. (ideally CMake would just skip empty mocs_compilation.cpp & its object file one day) * enables compiler to see all methods of a class in same compilation unit to do some sanity checks * potentially more inlining in general, due to more in the compilation unit * allows to keep using more forward declarations in the header, as with the moc code being sourced into the cpp file there definitions can be ensured and often are already for the needs of the normal class methods
2023-07-05 06:30:14 +00:00
#include "moc_cursoritem.cpp"
Reference in a new issue Copy permalink