About some old and hard to maintain effects

[Aleix Pol]

On Mon, May 31, 2021 at 10:54 AM Vlad Zahorodnii
<vlad.zahorodnii at kde.org> wrote:
>
> 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

Do you think these effects could be implemented using other
non-deprecated abstractions?

I'd say it's fine to remove them for now but I'd make sure that we are
not cornering ourselves.

Aleix