This effect is meant to be as a replacement for the present windows and
the desktop grid effect. It is written using QML.
So far, this effect implements only the basic features of the present
windows effect. Desktop management features will be added later.
CCBUG: 295775
CCBUG: 303438
This reverts commit ac16bef409.
It causes crashes and color channels seem to be swapped.
GLTexture::toImage() needs more work before it can be used in the
screenshot effect, or maybe dropped.
Makes it possible to apply the dpms settings per screen instead of
applying it to all of them, which is wrong at many levels.
Will be even more important with other effects like rotation.
This allows creating a GLTexture object and attaching a dmabuf to it.
Currently, we can do that by using the foreign GLTexture constructor,
but it makes the deletion of the texture handle more error prone.
In the future, we can add a method that allocates the texture storage,
but there's no need for that yet.
The pointing finger cursor is used to show that a piece of text is a
clickable link, and it is inappropriate to use it in other contexts.
Regular UI elements that do something when single-clicked continue to
use the standard arrow cursor in other contexts, so let's follow that
convention in the Present Windows and Desktop Grid effects too.
BUG: 421928
FIXED-IN: 5.23
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.
