The indirection no longer required because libkwineffects has been
merged with libkwin. EffectWindow will be eventually dropped in favor
of apis provided by Window and WindowItem.
If a repaint is scheduled in the prePaintScreen() function, we want
it to be applied in the next frame, not the current one.
Currently, it doesn't work like this because prePaintScreen() runs first
then the Compositor gathers repaints and resets them.
This is important to qtquick effects that use qtquick3d as some items in
qtquick3d schedule repaints for the next frame after synchronizing, i.e.
in OffscreenQuickView::update() which is called in prePaintScreen() by
QuickSceneEffect.
EffectWindowImpl affects rather the WindowItem, so move its ownership to
it. This encapsulates compositing setup so it's effectively same as
creating a window item, except some annoyances on X11.
Currently when we move the mouse the one render loop triggers a repaint.
When the cursor layer needs a new update we end up in the compositor
repainting the main content.
Even though painting should mostly no-op it still goes through all
existing items and effects to collect damage, still potentially making
the GL context current which could stall. A waste when we know we
haven't got anything to do. It's enough to cause noticable mouse lag on
some hardware.
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
This change adds support for xdg_wm_base v6, which introduces
xdg_toplevel suspended state.
The suspended state is tied to the visibility of the window item so the
effects could possibily "resume" window content updates.
Use the linear filter to ensure that the cursor doesn't look blocky with
some scale factors and use the clamp-to-edge wrap mode to avoid
potential artifacts when the image is scaled.
At the moment, the SurfaceItem needs to track individual properties that
may contribute to the buffer source box. That's error prone.
To fix that, this change makes the SurfaceInterface indicate when the
source box has changed and the SurfaceItem should sync its source box,
discard quads, etc.
At the moment, graphics buffers coming from wayland and internal windows
use different code paths to update textures. However, they don't have
to.
If the internal windows are ported to GraphicsBuffer, it will be
possible to unify SurfacePixmapInternal and SurfacePixmapWayland to make
pixmap logic a bit simpler.
The buffer source box is synchronized when the surface-to-buffer matrix
changes. However, when using 100% scaling, it's likely that the
surface-to-buffer matrix will be identity and therefore no corresponding
signal to indicate the change will be emitted.
To fix that, we need to update the buffer source box also when the
buffer size changes.
In some cases, it's desired to know what the inverse transform of a
given output transform is. It's possible to make it work by providing
helper functions, but we tend to avoid doing so.
This change converts the OutputTransform from an enum to a class so it's
possible to have both data + methods in the same type. Unfortunately,
unlike Rust, C++ provides no way to attach methods to enums, classes and
structs is the only way to go.
Being in the KWin namespace has a couple of advantages: the enum can be
forward declared, and the transform can be replaced with a slightly more
complex but useful type.
If the surface item's contents is scaled, i.e. its scale factor doesn't
match the output's scale, GL_LINEAR will be applied to smooth the
contents. The unfortunate thing is that it's possible some of the
changed pixels will bleed to the neighbor ones.
In order to handle that scenario better, this change makes the
SurfaceItem expand the damage if there's scale factor mismatch.
bufferSourceBox and bufferTransform properties were introduced to detect
if the surface contents is going to be scaled. bufferSourceBox covers
both crop transform from wp_viewport and scale factor from wl_surface.
bufferTransform is same as wl_surface's buffer transform property.
* speeds up incremental builds as changes to a header will not always
need the full mocs_compilation.cpp for all the target's headers rebuild,
while having a moc file sourced into a source file only adds minor
extra costs, due to small own code and the used headers usually
already covered by the source file, being for the same class/struct
* seems to not slow down clean builds, due to empty mocs_compilation.cpp
resulting in those quickly processed, while the minor extra cost of the
sourced moc files does not outweigh that in summary.
Measured times actually improved by some percent points.
(ideally CMake would just skip empty mocs_compilation.cpp & its object
file one day)
* enables compiler to see all methods of a class in same compilation unit
to do some sanity checks
* potentially more inlining in general, due to more in the compilation unit
* allows to keep using more forward declarations in the header, as with the
moc code being sourced into the cpp file there definitions can be ensured
and often are already for the needs of the normal class methods
This allows us to avoid losing precision when updating surface pixmaps.
Surface damage needs special handling either way.
Another advantage from switching to buffer damage is that it lets us to
decouple surface textures from surface items, which is useful for making
surface helpers more reusable.
Floating point arithmetic and/or the use of GL_LINEAR in the pipeline,
may result in visual glitches due to rounding (errors). As a short-term
fix until a proper (more involved) solution is in place for Plasma 6,
pad the damage slightly in all directions to alleviate those effects.
If a closed window is kept alive, it means that somebody needs to
animate it and therefore it should be visible. Otherwise the window
would be destroyed and its item would be removed from the scene.
This change makes the WindowItem not change its visibility if the
associated window is closed. If the window had been invisible before
it was closed, the item would be invisible; if the window had been
visible before it was closed, the item would be visible.
