As is, libkwineffects doesn't use any specific apis in kwayland-server,
it simply "forwards" wayland display and surfaces from libkwin. Given
that, there is no need to link libkwineffects with kwayland-server. If
an effect needs to access wayland specific stuff, it can link explicitly
against kwayland-server.
The main motivation behind this change is to further loosen up
dependencies between various kwin components and kwayland-server so the
latter can be moved back to kwin.
With the LEDs enum being defined in kwinglobals.h, wayland_server.h
won't need to include keyboard_input.h, which is good for compilation
times and wayland_server.h will drag less stuff, e.g. QtWidgets (input.h
includes QAction)
At the moment we'll be setting the YInverted setting, but in practice
that won't have any effect as it only changes the render matrix and
we'll end up streaming inverted textures.
This change addresses it by rendering it into another texture first to
resolve this situation and then download that new texture instead.
EffectQuickView is used by Aurorae. As long as Aurorae decorations are
rendered by kwin, it's not a problem. However, kde-gtk-config kded
module can also render them. This creates a problem. If effects object
is not created, accessing any of its getters or setters will result in a
segmentation fault.
This change rewrites the share context check so the effects object is
not accessed anymore.
One could argue that kde-gtk-config has to provide a dummy EffectsHandler
but it doesn't use effects and libkwineffects is not a dependency of
KDecoration2. So, providing a dummy EffectsHandler makes no sense.
In hindsight, we need to revisit the usage of EffectQuickView in Aurorae
as accessing the EffectsHandler in EffectQuickView is a totally valid
usecase and integration of QOpenGLContext.
BUG: 441585
This lays down some groundwork for realtime gestures in Wayland,
so that gestures that are 1:1 with user motion on a touchpad are
now possible to implement.
Due to earlier commits, this is mostly just glue code to make a
convenient API.
Gestures implemented with this API are four-finger gestures, to
avoid conflicting with apps that may use two or three-finger
gestures.
This change avoids unnecessary copying of QImage data when updating
textures using QImages that have non-ARGB32_Premultiplied formats.
There are three cases where texture unpacking can not be done/is
not worth doing: if GLES is used, and the extension for unpacking
subimages is not supported; if the entire image is being updated;
or if a format conversion needs to be done, in which case only the
region to update will have its format converted, and the resulting
image can be passed directly to glTexSubImage2d without setting
unpacking parameters.
SceneOpenGLShadow::prepareBackend used to use QImage::Format_Indexed8,
plus a special code path in GLTexture, to create single-channel OpenGL textures.
Now that Qt supports QImage::Format_Alpha8, this workaround can be removed.
Deleting QQuickWindow will force any remaining runnables to complete.
This is important for any items (such as our new ThumbnailItem) that
deletes resources in queued cleanups.
We need to invoke this manually whilst we still have an active render
control with a valid context, otherwise remaining runnables will no-op.
We also then want to manually delete our scene contents before the view
so they're not orphaned temporarily.
This fixes a memory leak observed with the new Overview effect.
In GLTexture::update, reuse the mechanism from the GLTexture(QImage, ...)
constructor to upload QImage data directly when the QImage format
has compatible GL format and type codes. Before this change, all QImage
formats other than ARGB32_Premultiplied required a format conversion.
QImage is implicitly shared. However, methods such as QImage::bits() may
detach. In order to avoid the detach, one either needs make the image
const or use QImage::constBits() method.
Currently, the GLTexture class uses QImage::bits() all over the place.
It prevents implicit detaching by storing images in const variables. Such
code is fragile. Adding an intermediate (optional) conversion step may
result in odd performance regressions.
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.
It's unused and the advantages of keeping it are outweighed by the
disadvantages - the returned value is dependant on the window type.
If you need to draw a drop-shadow that matches the shape of the window
or something along that line, render the window into an offscreen
texture and sample the alpha channel in a fragment shader.
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.
If a redirected animation reaches the end, the timeline value will be 0,
i.e. the interpolated() function has to return the from value, not `to`.
BUG: 438368
If a window is animated using DeformEffect, allocate an offscreen
texture with the scale factor of the screen where the window is
considered to be on.
Also, resize the offscreen texture on demand in order to make resource
handling more efficient.
At the moment, we handle window quads inefficiently. Window quads from
all items are merged into a single list just to be broken up again.
This change removes window quads from libkwineffects. This allows us to
handle window quads efficiently. Furthermore, we could optimize methods
such as WindowVertex::left() and so on. KWin spends reasonable amount
of time in those methods when many windows have to be composited.
It's a necessary prerequisite for making wl_surface painting code role
agnostic.
The scene items depend on the scene windows for caching window quads.
The goal of this change is to move window quads management to item.
Merging window quads in one list and then splitting them is inefficient,
it will be highly desirable if window quads are removed from the public
api so we can optimize window quad management.
With this change, the window quad type becomes irrelevant to render
backends for the most part. Note that the Xrender backend is a bit
nitpicky about window quads, so the shadow item doesn't create generic
"WindowQuadShadow" quads anymore.
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.
It was needed to work around visual glitches in the wobbly windows
effect. Since the wobbly windows effect renders the animated window into
an offscreen texture, we don't need this workaround anymore.
Furthermore, rather than using half-pixel correction, it is more
desirable to use an offscreen texture as it results in simpler design.
Performance-wise, it's not that bad that we need to start looking for
other ways to get rid of the seams between window contents and deco.
DeformEffect is the base class for effects that transform the window
quad grid, e.g. wobbly windows or magic lamp. The main difference
between normal effects and offscreen effects is that the latter renders
animated windows into offscreen textures which are later deformed.
The offscreen texture approach is superior to the half-pixel correction
approach as it produces more visually appealing results. Even with
half-pixel correction, you're still going to see jagged lines between
the main surface and the server-side decoration or drop-shadow.
It is also needed to reduce the number of usages of WindowPaintData::quads
which is needed to move forward with the scene redesign goal.
With high DPI we can't use the image size as a logical size directly.
The other change is use of QPainter::drawImage(QRect target, QImage
image, QRect source)
This slightly confusing method uses logical pixels for the target, but
the source rect is in native pixels of the source.
BUG: 422342
