Enabling lightlyshaders makes plasma laggy

[hellojaccc]

Enabling lightlyshaders effect makes animations laggy when lot of windows are open.

openSUSE Tumbleweed

Probably related:
76fb7e1

[a-parhom]

Please make sure that you have pulled the latest changes from the master branch, rebuilt and reinstalled the effect. The commit you are referencing to is not relevant any more, because now the effect uses entirely different approach to restore shadows.

Though it may need some optimization anyway. I'll look into it next week.

[hellojaccc]

Hi, thanks for this fix.

I have pulled the latest changes, and rebuilt/reinstalled the effect.

[a-parhom]

@hellojaccc Please, check if the latest changes in master branch make any difference for you in performance.

[hellojaccc]

Thanks for this amazing effect.

It doesn't fix the performance for me :( it's possible that my gpu isn't powerful enough since i use iGPU.

[a-parhom]

Well, that's a pity. However, I have some more ideas how the performance could be enhanced. I'll try that in a few days and if anything of it will make a measurable enhancement, I'll push it to this repo.

[a-parhom]

@hellojaccc I've added some more optimizations in the last commit. Can't say that it introduces significant difference on my machine, but seems that it is all we can do when using this approach of restoring shadows, unfortunately.

[sevenzerotwo]

Hi, i have the same performance problem as @hellojaccc . I'm running it on my Kubuntu 21.10 in VMWare with 3D acceleration enabled (well, cannot expect much from VM) but in one of your old commits the performance is more better than right now. I built and ran your old commit in my Debian Testing (bookworm) on VMWare with 3D acceleration enabled (about November 12/14 ago), and the performance was good even it's on VM. I try to move the binaries that i built on my Debian VM to Kubuntu VM and replacing it, and turns out the performance is better.
Here is the comparison:

This is the performance graph when running the latest commit.

And this is the performance graph when running the old commit.

The old commit source code was accidentally removed on my Debian VM, so i just have the compiled binaries. This is the config interface of old commit that i talked about:

Maybe the performance hit is because of different approach to restore shadows?

[a-parhom]

@sevenzerotwo Did you try the latest version with all the optimizations that I did a couple of days ago? If you did and It couldn't solve the performance problem for you, you can checkout the commit 3f1b370, it is the last commit when the effect used the previous approach of shrinking shadow.

[sevenzerotwo]

@a-parhom Yes, i just pulled the git for building again about hours ago and the performance didn't work well. Seems like for now i would try the last commit you mentioned. Thank you and also thank you for your work, it's amazing! Hope the performance could improved on new approach of shrinking in the future.

@hellojaccc maybe you could try build the commit mentioned by parhom if you still having the issues

[hellojaccc]

Thank you so much. i built from the mentioned commit, and it works much much better! (actually, i don't feel any slowness)

[a-parhom]

I've rewritten the plugin so that all the shadow restoration stuff is happening inside the shader itself, on the GPU. The textures now are not converted to images and back. I can see better performance on my hardware. You can try to compile from branch "performance_optimizations". I'll test that myself for some more time and merge it to master.

[jsebean]

I compiled the branch and the corners had black squares. Additionally, kwin still stutters, so I'm not certain I notice any performance difference.

[a-parhom]

Did you have any error messages in console after KWin restart? Also, could you please tell me some more info about your system? What video card do you have, what Plasma version and video drivers do you use? Is that on X11 or Wayland and do you have hidpi monitor? For now I can't reproduce your problem on any of my machines.

[a-parhom]

I've pushed some more improvements to the "performance_optimizations" branch. Now the plugin processes only visible regions of windows and skips everything that is hidden beneath other windows or is not on the active virtual desktop. Still needs some testing, so not merging to master at this point.

[jsebean]

Hi there, thanks for getting back so quickly.
On the last report I did not restart kwin, so perhaps I should have before posting that, however I just tested your new patches in the performance_optimizations branch and it seems to be working much better, no black corners either.

For specs:
CPU: Ryzen 7 3700X
GPU: RX 580 Nitro 4GB

I have a dual Monitor setup, my primary monitor is 240hz and secondary is 75hz. Both are 1080p, nothing hidpi and no scaling of any sort. I am using the X11 session, not Wayland, and the only configuration I have on X is enable TearFree with the xf86-video-amdgpu driver. This allows kwin to render at the FPS of the primary monitor rather than sync to the slowest monitor, without having tearing on the slower monitor.

The system has 32GB of DDR4-3200MT/s. I am running Arch Linux (btw) with KDE Plasma 5.23.5, however I'm using kwin_lowlatency instead of kwin itself.

I can still reproduce some stutter if I really try to stress the system. I don't consider it bad enough to not use the effect anymore however, because you really have to try, but for the sake of mentioning it I'll describe how to reproduce it.
Here's how:

1. Launch several konsole instances (I have it bound to Ctrl+Alt+T so it's quick). My Konsole profile is configured with blur which seems to stress it more so than, say, many instances of Dolphin, however it will still stutter slightly if I launch many Dolphin instead.
2. Visit testufo.com in Chrome to notice the stutter, Chrome will continue to render at 240fps, but with many terminals open, even if Chrome is on top of the open terminals, it will stutter.

A couple points to mention:

1. Apps that appear to use CSD (like Chrome, or GTK applications), when they are on top do not appear to stop the stutter, as if your patch is not detecting these Windows are on top.
2. If I open a native KDE application, like System Settings or Dolphin, and they cover the space that the terminals are occupying, the stutter goes away.

Anyhow, from regular usage I don't notice any issues, so thanks so much for all the effort :)
Kind regards,
-Jonah

[a-parhom]

Thank you for your report!
Looks like the issue with CSD apps may be connected with some bugs in my algorithm of verifying which areas should be painted. It needs some polishing. I'll return to it in a week or two. After fixing the bugs I'll merge "performance_optimizations" branch to master.

[a-parhom]

Seems to be rather stable now. Merged all changes to master.

[ryu-ketsueki]

I'll get to testing the new changes on master asap

[a-parhom]

@hellojaccc @sevenzerotwo Please, try the latest changes in master branch.

[hellojaccc]

Thanks for letting me know, it's much better than before :)
When maximizing a window, window's edge is black

[a-parhom]

It's a known issue (#15), I'll see what can be done, in a week, maybe.

[a-parhom]

Issue #15 is closed.

[cachandlerdev]

Unfortunately, even with a fairly powerful GPU (RTX 2070 Super), LightlyShaders still has a noticeable impact on KDE's performance when several applications are opened (i.e. Libreoffice, a couple browser tabs, and Dolphin).

[a-parhom]

Did you make sure to pull the latest changes from the master branch? It has a bunch of optimisations.

In any case, the effect has to use graphics resources to restore shadows in the cut out regions and that can be laggy. For now it looks like there's nothing else that can be improved in terms of performance. That's why I keep this issue open, sorry.

[a-parhom]

By the way, it looks weird that you are having all that performance issues with RTX 2070. I have GTX 1060 and don't have any problems with performance at all. Are you sure you have your video drivers set up properly?

[cachandlerdev]

I'm on 510.47.03. As far as I know, everything should be set up properly, since things like games work fine. From what you said on the other issue I posted, however, it seems like I'm probably having issues because I almost always have windows on the screen edges, or maximized.

(I'm using the version from the AUR which was updated 3 days ago, so I think I'm on the current build.)

[a-parhom]

Yes, that's the most likely cause of performance hit. I'll try to improve the algorithm used for rejecting processing of hidden areas to correctly work with maximized windows. Maybe in a week or two.

[a-parhom]

I'll close this as main optimizations have been made and the performance is really not so bad now.