3725d67ee1
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.
33 lines
619 B
C++
33 lines
619 B
C++
/*
|
|
SPDX-FileCopyrightText: 2022 Vlad Zahorodnii <vlad.zahorodnii@kde.org>
|
|
|
|
SPDX-License-Identifier: GPL-2.0-or-later
|
|
*/
|
|
|
|
#pragma once
|
|
#include <QObject>
|
|
#include <memory>
|
|
|
|
#include "core/renderlayerdelegate.h"
|
|
|
|
namespace KWin
|
|
{
|
|
|
|
class GLFramebuffer;
|
|
class GLTexture;
|
|
|
|
class CursorDelegateOpenGL final : public QObject, public RenderLayerDelegate
|
|
{
|
|
Q_OBJECT
|
|
|
|
public:
|
|
~CursorDelegateOpenGL() override;
|
|
|
|
void paint(RenderTarget *renderTarget, const QRegion ®ion) override;
|
|
|
|
private:
|
|
std::unique_ptr<GLTexture> m_texture;
|
|
std::unique_ptr<GLFramebuffer> m_framebuffer;
|
|
};
|
|
|
|
} // namespace KWin
|