About some old and hard to maintain effects

[Vlad Zahorodnii]

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