On Mon, May 31, 2021 at 10:54 AM Vlad Zahorodnii <vlad.zahorod...@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