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

74 lines
2.5 KiB
C++
Raw Normal View History

Port software cursor to RenderLayer Software cursor has always been a major source of problems. Hopefully, porting it to RenderLayer will help us with that. Note that the cursor layer is currently visible only when using software cursor, however it will be changed once the Compositor can allocate a real hardware cursor plane. Currently, software cursor uses graphics-specific APIs (OpenGL and QPainter) to paint itself. That will be changed in the future when rendering parts are extracted from the Scene in a reusable helper.
2022-02-05 09:47:00 +00:00
/*
SPDX-FileCopyrightText: 2022 Vlad Zahorodnii <vlad.zahorodnii@kde.org>
SPDX-License-Identifier: GPL-2.0-or-later
*/
Simplify software cursor implementation With RenderTarget, CursorView and CursorDelegate can be merged.
2022-04-12 13:14:23 +00:00
#include "cursordelegate_opengl.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 "composite.h"
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/renderlayer.h"
#include "core/rendertarget.h"
Port software cursor to RenderLayer Software cursor has always been a major source of problems. Hopefully, porting it to RenderLayer will help us with that. Note that the cursor layer is currently visible only when using software cursor, however it will be changed once the Compositor can allocate a real hardware cursor plane. Currently, software cursor uses graphics-specific APIs (OpenGL and QPainter) to paint itself. That will be changed in the future when rendering parts are extracted from the Scene in a reusable helper.
2022-02-05 09:47:00 +00:00
#include "cursor.h"
#include "kwingltexture.h"
#include "kwinglutils.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/cursorscene.h"
Port software cursor to RenderLayer Software cursor has always been a major source of problems. Hopefully, porting it to RenderLayer will help us with that. Note that the cursor layer is currently visible only when using software cursor, however it will be changed once the Compositor can allocate a real hardware cursor plane. Currently, software cursor uses graphics-specific APIs (OpenGL and QPainter) to paint itself. That will be changed in the future when rendering parts are extracted from the Scene in a reusable helper.
2022-02-05 09:47:00 +00:00
cursordelgate: round cursor position when rendering Otherwise there can be weird artifacts when screen scaling is involved
2023-02-20 15:22:24 +00:00
#include <cmath>
Port software cursor to RenderLayer Software cursor has always been a major source of problems. Hopefully, porting it to RenderLayer will help us with that. Note that the cursor layer is currently visible only when using software cursor, however it will be changed once the Compositor can allocate a real hardware cursor plane. Currently, software cursor uses graphics-specific APIs (OpenGL and QPainter) to paint itself. That will be changed in the future when rendering parts are extracted from the Scene in a reusable helper.
2022-02-05 09:47:00 +00:00
namespace KWin
{
Simplify software cursor implementation With RenderTarget, CursorView and CursorDelegate can be merged.
2022-04-12 13:14:23 +00:00
CursorDelegateOpenGL::~CursorDelegateOpenGL()
Port software cursor to RenderLayer Software cursor has always been a major source of problems. Hopefully, porting it to RenderLayer will help us with that. Note that the cursor layer is currently visible only when using software cursor, however it will be changed once the Compositor can allocate a real hardware cursor plane. Currently, software cursor uses graphics-specific APIs (OpenGL and QPainter) to paint itself. That will be changed in the future when rendering parts are extracted from the Scene in a reusable helper.
2022-02-05 09:47:00 +00:00
{
}
Simplify software cursor implementation With RenderTarget, CursorView and CursorDelegate can be merged.
2022-04-12 13:14:23 +00:00
void CursorDelegateOpenGL::paint(RenderTarget *renderTarget, const QRegion &region)
Port software cursor to RenderLayer Software cursor has always been a major source of problems. Hopefully, porting it to RenderLayer will help us with that. Note that the cursor layer is currently visible only when using software cursor, however it will be changed once the Compositor can allocate a real hardware cursor plane. Currently, software cursor uses graphics-specific APIs (OpenGL and QPainter) to paint itself. That will be changed in the future when rendering parts are extracted from the Scene in a reusable helper.
2022-02-05 09:47:00 +00:00
{
cursor: make position, hotspot and size floating point This allows all pixel positions to be used on high dpi screens, and corrects damage tracking with Xwayland cursors CCBUG: 466094
2023-02-19 23:35:44 +00:00
if (!region.intersects(layer()->mapToGlobal(layer()->rect()).toAlignedRect())) {
Simplify software cursor implementation With RenderTarget, CursorView and CursorDelegate can be merged.
2022-04-12 13:14:23 +00:00
return;
}
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
// Render the cursor scene in an offscreen render target.
cursor: make position, hotspot and size floating point This allows all pixel positions to be used on high dpi screens, and corrects damage tracking with Xwayland cursors CCBUG: 466094
2023-02-19 23:35:44 +00:00
const QSize bufferSize = (Cursors::self()->currentCursor()->rect().size() * renderTarget->devicePixelRatio()).toSize();
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
if (!m_texture || m_texture->size() != bufferSize) {
m_texture = std::make_unique<GLTexture>(GL_RGBA8, bufferSize);
m_framebuffer = std::make_unique<GLFramebuffer>(m_texture.get());
}
Port software cursor to RenderLayer Software cursor has always been a major source of problems. Hopefully, porting it to RenderLayer will help us with that. Note that the cursor layer is currently visible only when using software cursor, however it will be changed once the Compositor can allocate a real hardware cursor plane. Currently, software cursor uses graphics-specific APIs (OpenGL and QPainter) to paint itself. That will be changed in the future when rendering parts are extracted from the Scene in a reusable helper.
2022-02-05 09:47:00 +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
RenderTarget offscreenRenderTarget(m_framebuffer.get());
offscreenRenderTarget.setDevicePixelRatio(renderTarget->devicePixelRatio());
Port software cursor to RenderLayer Software cursor has always been a major source of problems. Hopefully, porting it to RenderLayer will help us with that. Note that the cursor layer is currently visible only when using software cursor, however it will be changed once the Compositor can allocate a real hardware cursor plane. Currently, software cursor uses graphics-specific APIs (OpenGL and QPainter) to paint itself. That will be changed in the future when rendering parts are extracted from the Scene in a reusable helper.
2022-02-05 09:47:00 +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
RenderLayer renderLayer(layer()->loop());
renderLayer.setDelegate(std::make_unique<SceneDelegate>(Compositor::self()->cursorScene()));
renderLayer.delegate()->prePaint();
renderLayer.delegate()->paint(&offscreenRenderTarget, infiniteRegion());
renderLayer.delegate()->postPaint();
Port software cursor to RenderLayer Software cursor has always been a major source of problems. Hopefully, porting it to RenderLayer will help us with that. Note that the cursor layer is currently visible only when using software cursor, however it will be changed once the Compositor can allocate a real hardware cursor plane. Currently, software cursor uses graphics-specific APIs (OpenGL and QPainter) to paint itself. That will be changed in the future when rendering parts are extracted from the Scene in a reusable helper.
2022-02-05 09:47:00 +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
// Show the rendered cursor scene on the screen.
cursor: make position, hotspot and size floating point This allows all pixel positions to be used on high dpi screens, and corrects damage tracking with Xwayland cursors CCBUG: 466094
2023-02-19 23:35:44 +00:00
const QRectF cursorRect = layer()->mapToGlobal(layer()->rect());
Properly scale cursordelegate_opengl to device geometry Rather than converting to logical to then later on convert back to device.
2022-08-18 10:16:53 +00:00
const qreal scale = renderTarget->devicePixelRatio();
Port software cursor to RenderLayer Software cursor has always been a major source of problems. Hopefully, porting it to RenderLayer will help us with that. Note that the cursor layer is currently visible only when using software cursor, however it will be changed once the Compositor can allocate a real hardware cursor plane. Currently, software cursor uses graphics-specific APIs (OpenGL and QPainter) to paint itself. That will be changed in the future when rendering parts are extracted from the Scene in a reusable helper.
2022-02-05 09:47:00 +00:00
QMatrix4x4 mvp;
Properly scale cursordelegate_opengl to device geometry Rather than converting to logical to then later on convert back to device.
2022-08-18 10:16:53 +00:00
mvp.ortho(QRect(QPoint(0, 0), renderTarget->size()));
cursordelgate: round cursor position when rendering Otherwise there can be weird artifacts when screen scaling is involved
2023-02-20 15:22:24 +00:00
mvp.translate(std::round(cursorRect.x() * scale), std::round(cursorRect.y() * scale));
Port software cursor to RenderLayer Software cursor has always been a major source of problems. Hopefully, porting it to RenderLayer will help us with that. Note that the cursor layer is currently visible only when using software cursor, however it will be changed once the Compositor can allocate a real hardware cursor plane. Currently, software cursor uses graphics-specific APIs (OpenGL and QPainter) to paint itself. That will be changed in the future when rendering parts are extracted from the Scene in a reusable helper.
2022-02-05 09:47:00 +00:00
Make opengl cursor delegate push fbo This case was overlooked in 8071ade9a83b4c320f4d22bf2f727e20ffdf8324.
2022-12-20 15:48:05 +00:00
GLFramebuffer *fbo = std::get<GLFramebuffer *>(renderTarget->nativeHandle());
GLFramebuffer::pushFramebuffer(fbo);
Port software cursor to RenderLayer Software cursor has always been a major source of problems. Hopefully, porting it to RenderLayer will help us with that. Note that the cursor layer is currently visible only when using software cursor, however it will be changed once the Compositor can allocate a real hardware cursor plane. Currently, software cursor uses graphics-specific APIs (OpenGL and QPainter) to paint itself. That will be changed in the future when rendering parts are extracted from the Scene in a reusable helper.
2022-02-05 09:47:00 +00:00
// Don't need to call GLVertexBuffer::beginFrame() and GLVertexBuffer::endOfFrame() because
// the GLVertexBuffer::streamingBuffer() is not being used when painting cursor.
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
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_texture->bind();
Port software cursor to RenderLayer Software cursor has always been a major source of problems. Hopefully, porting it to RenderLayer will help us with that. Note that the cursor layer is currently visible only when using software cursor, however it will be changed once the Compositor can allocate a real hardware cursor plane. Currently, software cursor uses graphics-specific APIs (OpenGL and QPainter) to paint itself. That will be changed in the future when rendering parts are extracted from the Scene in a reusable helper.
2022-02-05 09:47:00 +00:00
ShaderBinder binder(ShaderTrait::MapTexture);
binder.shader()->setUniform(GLShader::ModelViewProjectionMatrix, mvp);
kwinglutils: use QSizeF instead of QRect The method is ignoring the position of the rectangle, which is very unintuitive when using it
2023-02-19 00:04:22 +00:00
m_texture->render(region, cursorRect.size(), scale);
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_texture->unbind();
Port software cursor to RenderLayer Software cursor has always been a major source of problems. Hopefully, porting it to RenderLayer will help us with that. Note that the cursor layer is currently visible only when using software cursor, however it will be changed once the Compositor can allocate a real hardware cursor plane. Currently, software cursor uses graphics-specific APIs (OpenGL and QPainter) to paint itself. That will be changed in the future when rendering parts are extracted from the Scene in a reusable helper.
2022-02-05 09:47:00 +00:00
glDisable(GL_BLEND);
Make opengl cursor delegate push fbo This case was overlooked in 8071ade9a83b4c320f4d22bf2f727e20ffdf8324.
2022-12-20 15:48:05 +00:00
GLFramebuffer::popFramebuffer();
Port software cursor to RenderLayer Software cursor has always been a major source of problems. Hopefully, porting it to RenderLayer will help us with that. Note that the cursor layer is currently visible only when using software cursor, however it will be changed once the Compositor can allocate a real hardware cursor plane. Currently, software cursor uses graphics-specific APIs (OpenGL and QPainter) to paint itself. That will be changed in the future when rendering parts are extracted from the Scene in a reusable helper.
2022-02-05 09:47:00 +00:00
}
} // namespace KWin
Reference in a new issue Copy permalink