kwin/src/cursordelegate_qpainter.h

/*
    SPDX-FileCopyrightText: 2022 Vlad Zahorodnii <vlad.zahorodnii@kde.org>

    SPDX-License-Identifier: GPL-2.0-or-later
*/

#pragma once

#include "core/renderlayerdelegate.h"

#include <QImage>

namespace KWin
{

class CursorDelegateQPainter final : public RenderLayerDelegate
{
public:
    void paint(RenderTarget *renderTarget, const QRegion &region) override;

private:
    QImage m_buffer;
};

} // namespace KWin
Simplify software cursor implementation With RenderTarget, CursorView and CursorDelegate can be merged. 2022-04-12 13:14:23 +00:00			`/*`
			`SPDX-FileCopyrightText: 2022 Vlad Zahorodnii <vlad.zahorodnii@kde.org>`

			`SPDX-License-Identifier: GPL-2.0-or-later`
			`*/`

			`#pragma once`

Move multi-purpose code in its own directory Things such as Output, InputDevice and so on are made to be multi-purpose. In order to make this separation more clear, this change moves that code in the core directory. Some things still link to the abstraction level above (kwin), they can be tackled in future refactors. Ideally code in core/ should depend either on other code in core/ or system libs. 2022-08-29 07:55:49 +00:00			`#include "core/renderlayerdelegate.h"`
Simplify software cursor implementation With RenderTarget, CursorView and CursorDelegate can be merged. 2022-04-12 13:14:23 +00:00
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 <QImage>`

Simplify software cursor implementation With RenderTarget, CursorView and CursorDelegate can be merged. 2022-04-12 13:14:23 +00:00			`namespace KWin`
			`{`

			`class CursorDelegateQPainter final : public RenderLayerDelegate`
			`{`
			`public:`
			`void paint(RenderTarget *renderTarget, const QRegion &region) override;`
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
			`private:`
			`QImage m_buffer;`
Simplify software cursor implementation With RenderTarget, CursorView and CursorDelegate can be merged. 2022-04-12 13:14:23 +00:00			`};`

			`} // namespace KWin`