WindowPaintData contains two projection matrices -
screenProjectionMatrix and projectionMatrix. I'm not sure why we have
two.
screenProjectionMatrix is initialized by the scene. While
projectionMatrix is usually updated by the effects. The two are not in
sync.
On the other hand, OffscreenEffect takes into account only
screenProjectionMatrix. It means that if a window is transformed by two
offscreen effects, the final result is going to be broken because
an OffscreenEffect must use the projection matrix specified by another
OffscreenEffect, which it doesn't.
This change cleans up projection matrix properties in WindowPaintData,
so there's only one projection matrix property. With that, offscreen
effects can be properly nested.
BUG: 462876
SurfaceInterface::scaleOverride() doesn't scale the bufferScale, so if the
scale override is 2, but the buffer scale specified by the client is 1,
bufferScale() will return 1.
Xwayland cursor surface implicitly relied on this behavior.
Porting cursor to SurfaceItem changed that. Now cursor surfaces honor
the scale override, which makes Xwayland cursors too small.
In order to properly fix, plasma has to scale Xcursor.size in xrdb. The
problem is that plasma also sets XCURSOR_THEME and XCURSOR_SIZE envvars
that take precedence. Plasma must stop setting those envvars, but it's
doable only with Qt 6.5, which got MouseCursorTheme and MouseCursorSize
hints in QPlatformTheme.
Scene::Window::discardPixmap() used not to add damage. No idea how it
got in SurfaceItem::discardPixmap(). Perhaps a mishap when introducing
window items.
From logical point of view, adding damage when discard a pixmap is not
necessary too because a new pixmap is going to be created.
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.
While direct scanout happens, the damage of the SurfaceItem is reset, which
can cause the OpenGL texture to not be updated once direct scanout ends,
and leave the texture outdated until the surface is damaged again.
In order to fix that, make sure the texture is always fully updated after
the SurfaceItem has been used in direct scanout.
The main motivation behind this change is to share rendering code
between windows and the cursor, specifically the Item class which
requires a Scene.
Note that Scene subclasses are responsible for issuing
ItemRenderer::renderItem() calls. The main reason for that is the
current architecture of the effects system, specifically we need to call
some effects hooks before and after painting a window.
It makes the behavior of the ItemRendererQPainter compatible with the
behavior of the ItemRendererOpenGL. It is needed to ensure that the
cursor layer is properly cleared too.
This is needed to establish explicit connection between an item and the
scene it belongs to. For now, the scene must be known at the item
construction time. Perhaps it can be improved in the future by items
inheriting their scene from the parent item, but the scene would need to
be refactored more so there's a root item or something like that.
Currently, Item schedules repaints taking output geometry into account,
but that's going to work poorly for cases other than workspace scene.
Moving from Output to SceneDelegate also allows us to unify some X11 and
Wayland specific code paths in Item.
Furthermore, it ensures that effects->paintScreen() won't remove pending
repaints for the output.
It makes more sense for an output layer to return the render target fbo.
The user of the render target will then take appropriate steps to bind
the fbo. It reduces the amount of boilerplate code in output layers too.
The goal is to create surface items for things that are not in the
workspace scene. RenderBackend perhaps is not a great place for these
factory functions. On the other hand, this change merely rewires code
from Scene to RenderBackend. I think that in distant future we could
make surface items pick surface texture type on their own, for what it's
worth that's what we would do in QtQuick.
There's no any way to integrate OffscreenQuickView into the scene graph.
So make the EffectsHandlerImpl responsible for drawing quick views until
the corresponding item is introduced (requires a lot and a lot of
refactoring in effects) or the design of kwin changes so much that we
don't need this special code path.
ItemRenderer class provides Item rendering facilities. The main
motivation behind this change is to extract code that can be used to
render both normal windows as well as the cursor.
