Hi,
Currently, we redesign scene abstractions in kwin [1].
https://blog.vladzahorodnii.com/2021/04/12/scene-items-in-kwin/ outlines
the end goal and provides an explanation why the scene abstractions need
to be reworked. But just to summarize:
* kwin renders wayland surfaces differently depending on their role.
Furthermore, it makes assumptions about what types of client buffers can
be attached to surfaces based on their role. That is absolutely wrong!
For example, if a video game renders the pointer cursor using graphics
api such as Vulkan or OpenGL, kwin won't be able to display that cursor
* with the current scene abstractions, it's very difficult to render
wayland surfaces other than that used to represent window contents, for
example additional drag-and-drop icons. For what it's worth, dnd icons
are implemented with some hacks atm, which break on mobile devices :(
* more complex animations such as cross-fade animations can't be easily
implemented with the current scene api. Similar to dnd icons, cross-fade
animations are implemented as a hack, which doesn't work well
* with the desired scene design, the rendering logic will be separate
from scene items, i.e. scene items are used only to describe the
contents of the screen. It should make it easier adding support for
Vulkan; we could go one step further and perform compositing on threads,
which should result in more stable frame rates on multi-monitor setups
on wayland
Unfortunately, some of kwin's rendering abstractions are exposed in
libkwineffects (a library that's used to make effects). That means it's
nearly impossible to make major architectural advancements without
breaking effects in one or another way.
Over the course of the past weeks, we've been working on a replacement
for some of the apis in libkwineffects to allow us hide some rendering
logic and porting effects to the new apis. However, there are still a
few problematic effects. These effects are **massive** code-wise and not
many people fully understand how they work. Another issue with them is
that they use QTimeLine not the way it's designed. Essentially, those
effects have to be re-written from scratch. On the other hand, based on
support information from various bug reports, it doesn't look like those
effects are used widely. So, given that disadvantages of keeping those
hard to maintain effects outweigh the advantages and limited man power
of the kwin development team, we'd like to remove them.
I believe that all the effort that could have been spent on rewriting
the problematic effects can be redirected on more important tasks in the
scene redesign goal and improving QtQuick integration in KWin.
The effects that we would like to drop are
* coverswitch
* cube
* cubeslide
* flipswitch
On a related note, we plan to have a BoF session at this year's Akademy
[2] about declarative effects api. Please join us if you have thoughts
on this matter. :)
Regards,
Vlad
[1] https://invent.kde.org/plasma/kwin/-/issues/30
[2] https://akademy.kde.org/2021
