The Xrender backend was added at the time when OpenGL drivers were not
particularly stable. Nowadays though, it's a totally different situation.
The OpenGL render backend has been the default one for many years. It's
quite stable, and it allows implementing many advanced features that
other render backends don't.
Many features are not tested with it during the development cycle; the
only time when it is noticed is when changes in other parts of kwin break
the build in the xrender backend. Effectively, the xrender backend is
unmaintained nowadays.
Given that the xrender backend is effectively unmaintained and our focus
being shifted towards wayland, this change drops the xrender backend in
favor of the opengl backend.
Besides being de-facto unmaintained, another issue is that QtQuick does
not support and most likely will never support the Xrender API. This
poses a problem as we want thumbnail items to be natively integrated in
the qtquick scene graph.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
EffectWindow::shape() doesn't fit the item based design. This change
ports the blur effect away from the shape() function to the rect()
function. The XShape extension was introduced when windows with an alpha
channel wasn't really a thing. Setting a shape served as a way to clip a
window, the most notable example is xeyes.
If an application relies on the xshape extension to actually clip the
window and not to force the window manager not to put the server-side
deco, it most likely doesn't support translucency and therefore it
shouldn't set the blur region to begin with.
This change makes the blur effect ignore the xshape region similar to
the background contrast effect. It allows us to decouple a bit more
effects from the rest of rendering machinery and thus make it easier for
us to move forward with the scene redesign goal.
Similar to the slide effect, the desktop grid can use the clip region to
clip windows when needed. This will improve performance because the desktop
grid effect will do less work. Currently, it clips quads on its own in
prePaintWindow, copies them over in a temporary list, and lets the opengl
scene clip the window quads again.
We can clip windows differently by just passing a custom region to the
paintWindow() function down the effects chain, which the desktop grid
effect already does.
The old behavior and the old bugs are preserved. The Xrender code path is
unaffected.
In general, on Wayland, there is no such a thing as "window scale factor"
because sub-surfaces can have different buffer scales. However, we know
the scale factor of the output where the window is considered to be on. So
we can use the screen's scale factor as the window's scale factor. In
most cases, it will produce the correct result.
For the scene redesign, window quads need to be removed from the effects
api. This change ports the screenshot effect away from quads.
In order to exclude the server-side decoration from the window
screenshot, the effect will render the contents of the client geometry
into the offscreen texture. If the window is client-side decorated, the
entire window will be rendered as before.
The good thing about this approach is that the screenshot effect will do
less work, it won't loop over window quads to compute the bounding rect
or filter out the deco quads.
Many reasons have been brought up over the years for why this effect is
not appropriate to be enabled by default:
- It was designed to highlight the whizzy technical feature of being
able to make windows transparent, which is no longer particularly
impressive today.
- It looks visually dated.
- It can produce a confusing visual soup by blending a window being
moved or resized with the content below it, which we recently disabled
for the Highlight Windows effect.
- If one window is covering up another as a way to deliberately hide the
content of the lower window, this effect will reveal the hidden
content whenever the upper window is moved or resized at all.
Overall it does not seem to have enough advantages to offset these
issues. Let's disable it by default--but only for the people who did not
modify its configuration at all. We can assume that those people like
it, so let's keep it on for them.
BUG: 384054
FIXED-IN: 5.23
Closes Phab task T7915
On X11, the lockscreen greeter is an override-redirect window so the
scale and the glide effect ignore it.
On Wayland, the lockscreen greeter is a regular window so both effects
try to animate it upon the screen being unlocked, which looks bad.
According to the HIG, the InCubic easing curve should be used if the
animated item changes its state from visible to invisible and the
OutCubic easing curve if vice versa.
Since the scripted effects were ported to QJSEngine, it's possible now to
use ECMAScript 2015 perks such as classes, let and const.
This change ports the scale effect to some ES6 features to make the code
neater.
Reducing the oppacity of these windows causes them to appear as phantoms
in the corners of the screen. They look quite odd on top of anything else
in the corners of the screen, such as any Plasma panels.
However making them 100% opaque doesn;t work either, since then they
look interactive, but they're not, and can't be made so due to the
scripting API used here.
So our only real option to remove the weirdness is to make them 100%
transparent, and therefore show the entirety of the desktop with no sign
that the effect is in use.
The last presentation timestamps should be reset when all animations
finish rather than when the effect finishes. Otherwise, the calculated
time diff for the first animation frame will be too big.
BUG: 433471
Showing the panels makes this effect a little bit more integrated
with the desktop. With the panels disabled it creates a separate state,
with the panels enabled it creates a more friendly state with
the effect adding to the already existing experience.
