Currently, X11Window and Unmanaged call finishCompositing(), which tries
to destroy the window item and other associated compositing data.
Usually, it has no any effect on the window item and the effect window
because they are moved to the Deleted. However, it has some effect on
the XDamage handle.
If the X11 window is unmapped, it will destroy the XDamage handle. If
the X11 window is destroyed, it will do nothing. Why does it behave like
that? Because that's how the XDamage spec is written.
This change removes the call to finishCompositing() and refactors how
the XDamage is handled so Window::finishCompositing() is more generic.
If the X11 window is destroyed, SurfaceItemX11::forgetDamage() will be
called and SurfaceItemX11::~SurfaceItemX11() won't attempt to destroy
the damage handle.
If the X11 window is unmapped, SurfaceItemX11::destroyDamage() will be
called and destroyDamage() in SurfaceItemX11::~SurfaceItemX11() will
noop.
If compositing has been restarted, destroyDamage() in
SurfaceItemX11::~SurfaceItemX11() will destroy the damage handle.
When a window is closed, a Deleted object will be constructed and the
Window's properties will be copied over to it. The long term plan is to
stop doing that, i.e. keep the Window alive but just flip a few flags to
indicate that it's been closed.
In order to unify decoration management, this change ensures that it's
okay to have decorations live as long as the Deleted.
The order in which windows are painted is computed dynamically every
frame. On the other hand, with the introduction of items, it's desired
to avoid doing that so repaints can be scheduled as needed. The
unification also opens the possibilities for more rendering related
refactors to make the code nicer and more reusable.
Currently Deleted are destroyed with a delay to avoid dangling pointers
within the middle of painting.
On the other hand, it's reasonable to require not to delete windows when
kwin starts painting the screen.
Over the years, we refactored how deleted windows. They are always
unreferenced after finishing the current frame. So it should be fine to
destroy Deleted immediately now.
kwineffects.h is included in many files and not everyone needs the
RenderTarget and RenderViewport, so forward declare them to reduce the
amount of parsing work for the compiler.
The only purpose ScreenPaintData had was to pass around a copy of the viewport
projection matrix and the effectscreen, which can be handled in a simpler
way separately.
Instead of calling effects->renderTargetRect() and effects->renderTargetScale(),
pass the actually used render target and viewport in all the necessary methods.
This ensures that if an effect renders a screen with a modified scale or
projection matrix, the modified values get used instead of the "global" ones
Currently the Shadow class is scene specific, which adds coupling
between Window and scene bits.
This change introduces ShadowTextureProvider that contains scene
specific stuff so the Shadow acts like a data source and is not coupled
to concrete scene.
If a window is made ready for painting with some delay, the item won't
schedule an update. To fix that, sync the item visibility state with
Window::readyForPainting(). When the item visibility changes, a repaint
will be scheduled.
BUG: 464955
At quick glance, it doesn't seem like there's any benefit from storing
the shadow elements as pixmaps. It saves us some QImage <-> QPixmap
conversions too.
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.
