Re: About some old and hard to maintain effects
Of those, I think the cube effect will be the only one missed by a significant number of people. Maybe we could prioritize rewriting that one after the scene redesign, and let the other three die a dignified death? Nate
Re: About some old and hard to maintain effects
On Mon, May 31, 2021 at 10:22 AM Vlad Zahorodnii wrote: > > On 5/31/21 4:43 PM, Aleix Pol wrote: > > Do you think these effects could be implemented using other > > non-deprecated abstractions? > > Yes. Those effects need to render every animated window into an > offscreen texture and then do their thing, e.g. map the offscreen > texture on a cube or a cylinder, etc. The mechanics of getting the > offscreen texture will possibly change as we progress with the scene > redesign though. > I personally would be very sad if we lost those effects. I still use the cube effect to dazzle people. :P And yes, I still use it on one of my machines because I love being fancy. :) -- 真実はいつも一つ！/ Always, there's only one truth!
Re: About some old and hard to maintain effects
On Monday, 31 May 2021 10:53:58 CEST Vlad Zahorodnii wrote: > The effects that we would like to drop are > > * coverswitch > * cube > * cubeslide > * flipswitch So, I wanted to go and check them. The result is that they all have big UX issues. Like assuming 4 virtual desktops and only one monitor. Or no animation in the case of flipping through windows in flipswitch. It sounds like the code quality was the reason this wasn't made more polished and in my experience its then better to drop them and open up the space for new innovations.
Re: About some old and hard to maintain effects
On 5/31/21 4:43 PM, Aleix Pol wrote: Do you think these effects could be implemented using other non-deprecated abstractions? Yes. Those effects need to render every animated window into an offscreen texture and then do their thing, e.g. map the offscreen texture on a cube or a cylinder, etc. The mechanics of getting the offscreen texture will possibly change as we progress with the scene redesign though. Cheers, Vlad I'd say it's fine to remove them for now but I'd make sure that we are not cornering ourselves. Aleix
Re: About some old and hard to maintain effects
On Mon, May 31, 2021 at 10:54 AM Vlad Zahorodnii 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
About some old and hard to maintain effects
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
