Skip to content

scene: Introduce cursor item and scene

Vlad Zahorodnii requested to merge work/zzag/scene-cursor into master

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.

With this, kwin will be able to handle or at least gain capabilities to handle cases such as: cursors rendered using opengl or vulkan, cursors with subsurfaces (weird, but technically legal, https://gitlab.freedesktop.org/emersion/wleird/-/merge_requests/34), cursors with viewports (e.g. when using fractional scaling), and other things that you could do with a wl_surface.

Post merge tasks:

  • Add CursorSource::size() property and port Cursor to it
  • Rework cursor image retrieval (needed by the screencast plugin and the screenshot effects), potentially means rendering the cursor scene in a scratch texture, then grabbing its content
  • Make WaylandEglCursorLayer::endFrame() pass dmabufs to the host compositor
  • Make cursor views persistent or at least get rid of cursor layer rendering in output backends, e.g. by implementing Xaver's specialized cursor type idea
Edited by Vlad Zahorodnii

Merge request reports