The Compositor contains nothing that can potentially get dirty and need
repainting.
As is, the advantages of this move aren't really noticeable, but it
makes sense with multiple scenes.
Backend parts are far from ideal, they can be improved later on as we
progress with the scene redesign.
The main idea behind the render backend is to decouple low level bits
from scenes. The end goal is to make the render backend provide render
targets where the scene can render.
Design-wise, such a split is more flexible than the current state, for
example we could start experimenting with using qtquick (assuming that
the legacy scene is properly encapsulated) or creating multiple scenes,
for example for each output layer, etc.
So far, the RenderBackend class only contains one getter, more stuff will
be moved from the Scene as it makes sense.
The screen count can be retrieved by checking the number of items in the
EffectHandler.screens property.
The replacement for the numberScreensChanged signal are the screenAdded
and the screenRemoved signals.
The main motivation behind this change is to clean up the screens api
and reduce the number of usages of the Screens class.
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.
Active output is a window management concept. It indicates what output
new windows have to be placed on if they have no output hint. So
Workspace seems to be a better place for it than the Screens class, which
is obsolete.
Currently, the EffectsHandler has two signals that are emitted when the
combined geometry of all outputs change - virtualScreenGeometryChanged()
and screenGeometryChanged(). Having two signals is most likely a
historical artifact.
This change untangles the screenGeometryChanged() signal from the
Workspace and makes it the same as the virtualScreenGeometryChanged()
signal.
The main idea behind _NET_WM_FRAME_OVERLAP is to extend the borders of
the server-side decoration so the application can draw on top of it. It
was inspired by similar feature in Windows.
However, _NET_WM_FRAME_OVERLAP is basically unused. Neither GTK nor Qt
support it and I have never seen any application that uses it.
At the moment, kwin is the only compositing window manager that supports
_NET_WM_FRAME_OVERLAP. Neither mutter nor compiz nor compton and so on
support it.
Since _NET_WM_FRAME_OVERLAP is practically unused, there's no point for
keeping supporting it.
This change shouldn't affect any existing app as _NET_WM_FRAME_OVERLAP
atom is not listed in _NET_SUPPORTED.
Currently, thumbnail items are rendered by kwin. This means that qtquick
code cannot do things such as applying shader effects to window thumbnails
or simply draw custom controls on top of thumbnails.
With this change, task switchers and qml extensions will be able to
place their own contents on top of thumbnails and apply custom effects
to them.
In order to integrate window thumbnails, a window is rendered on kwin
side using its own opengl context. A fence is inserted in the command
stream to ensure that the qtquick machinery doesn't start using the
offscreen texture while there are still rendering commands being executed.
Thumbnails are rendered into offscreen textures as we don't have full
control over when qtquick windows render their contents and to work around
the fact that things such as VAOs can't be shared across OpenGL contexts.
WindowThumbnailItem and DesktopThumbnailItem act as texture providers.
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.
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 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 introduction of scene items, the Scene::Window::bufferShape()
method was removed as it makes no sense on wayland - a window may have
several sub-surfaces, so a single region to indicate the shape of the
window won't work.
SurfaceItem::shape() returns the shape of a surface. On Wayland, it
corresponds to the rect of the wl_surface. On X11, it corresponds to the
client window rect inside the frame window, or custom shape region if
the client has set one.
On the other hand, EffectWindow::shape() wants a completely different
thing. If the window is decorated, it needs to return the rect of the
decoration. Otherwise it has to return the shape region if there's one.
In the future, the EffectWindow::shape() function must be removed as it
doesn't fit the item based design. The main reason why we have it at
all is because the x server doesn't support translucency, setting a
shape region is a (hacky) way to work around that limitation, xeyes is
a notable example.
BUG: 437138
BUG: 435862
This is to improve code readability and make it easier to differentiate
between methods that are used during interactive move-resize and normal
move-resize methods in the future.
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.
Currently, dealing with sub-surfaces is very difficult due to the scene
design being heavily influenced by X11 requirements.
The goal of this change is to re-work scene abstractions to make improving
the wayland support easier.
The Item class is based on the QQuickItem class. My hope is that one day
we will be able to transition to QtQuick for painting scene, but in
meanwhile it makes more sense to have a minimalistic internal item class.
The WindowItem class represents a window. The SurfaceItem class represents
the contents of either an X11, or a Wayland, or an internal surface. The
DecorationItem and the ShadowItem class represent the server-side deco and
drop-shadow, respectively.
At the moment, the SurfaceItem is bound to the scene window, but the long
term plan is to break that connection so we could re-use the SurfaceItem
for things such as software cursors and drag-and-drop additional icons.
One of the responsibilities of the Item is to schedule repaints as needed.
Ideally, there shouldn't be any addRepaint() calls in the core code. The
Item class schedules repaints on geometry updates. In the future, it also
has to request an update if its opacity or visibility changes.
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.
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.
