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.
With the new interface, the compositor sends raw image data instead of
encoding it as a png image, which causes a lot of overhead on Wayland.
In addition to that, the new interface is more extensible, for example
we can add new options or change the written image data format, however
the latter is less likely to happen.
BUG: 433776
On Wayland, when the compositor sends a screenshot to the requesting
app, it encodes the screenshot as a PNG image and sends the encoded data
over the pipe. The requesting app (Spectacle) then needs to decode the
data.
The issue is that encoding PNG images is not cheap. This is the main
reason why Spectacle is shown with a huge delay after you press the
PrtScr key.
In order to fix the latency issue, we need to transfer raw image data.
Unfortunately, the current dbus api of the screenshot is too cluttered
and the best option at the moment is to start with a clean slate.
This change prepares the screenshot effect for versioned dbus interface.
Most of existing dbus logic was moved out in a separate class. In order
to schedule screen shots, the screenshot effect got some new API.
QFuture<QImage> scheduleScreenShot(window, flags)
QFuture<QImage> scheduleScreenShot(area, flags)
QFuture<QImage> scheduleScreenShot(screen, flags)
If a dbus interface needs to take a screenshot, it needs to call one of
the overloaded scheduleScreenShot() functions. Every overload returns a
QFuture object that can be used for querying the result.
This change also introduces "sink" and "source" objects in the dbus api
implementation to simplify handling of QFuture objects.
Note that the QFutureInterface is undocumented, so if you use it, you do
it on your own risk. However, since Qt 5.15 is frozen for non-commercial
use and some other Plasma projects already use QFutureInterface, this
is not a big concern. For what it's worth, in Qt 6, there's the QPromise
class, which is equivalent to the QFutureInterface class.
CCBUG: 433776
CCBUG: 430869
This provides the compositor a way to indicate what output is being
rendered. The effects such as the screenshot can check the provided
screen object in order to function as expected.
In QJSEngine, QRect is an Object, which is correct. This means that we
cannot use simple assignment operator to copy geometries, we need to use
standard ways to copy Objects, such as Object.assign() or the spread
operator, which is not available in QJSEngine yet.
Currently, the wobbly windows effect assumes that the window data will
be updated on every repaint. However, there are legit cases when the
time diff between frames can be 0, for example when per screen rendering
is on.
If we are unlucky enough and the geometry of the window changes in that
very short moment, the mapping between window quads and the bezier
patch will be wrong. The window will most likely bounce back and forth.
In order to improve handling of that tricky case, this change makes the
computeBezierPoint() function take the "uv" coordinates rather than the
absolute "xy" coordinates of window vertices. This loosens the
connection between the real geometry of the window and the cached bezier
patch, and overall makes the effect's timing code more robust.
This can be also useful if the wobbly windows effect starts accumulating
time diffs and performing the integration step every N msecs with the
purpose of maintaining uniform "wobbliness" across different refresh rates.
BUG: 433187
Once in a while, we receive complaints from other fellow KDE developers
about the file organization of kwin. This change addresses some of those
complaints by moving all of source code in a separate directory, src/,
thus making the project structure more traditional. Things such as tests
are kept in their own toplevel directories.
This change may wreak havoc on merge requests that add new files to kwin,
but if a patch modifies an already existing file, git should be smart
enough to figure out that the file has been relocated.
We may potentially split the src/ directory further to make navigating
the source code easier, but hopefully this is good enough already.
