Monocle layout is buggy with shadows on

[ikz87]

Monocle layout lets you put all tiled windows maximized, each behind the previous window.
I recently found a bug with animations that happens on bspwm monocle layout when using (the newly fixed) shadows:

out.mp4

Now, big disclaimer, I don't know anything about picom (or compositors, in general), but since this fork is using (I think) spring animations, shadows seem to somehow be messing something up with the dampening, that would explain why when setting clamping to true it kinda fixes the issue even if it still looks a little weird.

Traces generated in the video are found here (they were too large to upload to github)

[D3SK3R]

off-topic, sorry, but how did you get these animations for switching workspaces on bspwm? I thought it only worked with DWM, no matter what I try, animations simply change with no animation at all. Can you paste here your config file?

[ikz87]

You can find my config here

[FT-Labs]

Btw if workspace animations work it's weird, i dont think they are working.

How about this one?

157ecd2

[D3SK3R]

Btw if workspace animations work it's weird, i dont think they are working.

Yeah I found that weird too, I saw a post of you on reddit and asked if this animations would be possible in another WM besides dwm, you said that it's possible but isn't currently working, I took a look at his config, and here it isn't working either. Using bspwm just like he

[ikz87]

Just to be clear, only the animations for mapping and unmapping windows work, everything related to workspace animations doesn't work correctly in bspwm. @D3SK3R I think if you straight up copy my config and use it, the animations should work the exact same.

@FT-Labs I tried your recent fixes, but hate to say that the effect is exactly the same :/

Tho I might have found something.
When using shadows, my pc (it's a laptop with no dedicated GPU) lags a bit, and drops some frames when animations happen. I've started to see that the issue gets a lot worse when recording, meaning, it gets worse as performance gets worse. Maybe the rendering is skipping critical frames (like when the dampening direction switches?) and thus makes the window positions oscillate indefinitely? Not sure if that would be a possible anyway.

Also, realized just now that this issue might not be appropriate since this picom fork is mostly meant to be use with your fork of dwm and this issue seems like has to do mostly with bspwm stuff, so feel free to add a won't fix label and close it if you feel like it, it's ok :)

[FT-Labs]

Hello,

I wanna handle this issue :( This is my last try for today, I hope this will work kind of fine now. Shadows are really forcing the gpu, and I think rendering it so many times forces picom's session start. Could you try this one?

90f57e9

[ikz87]

No luck, still same behavior. Is there something I could do to help you figure out what might be causing this?

[FT-Labs]

Could you send a debug log and a new recording? And just to be clear, when you rerun picom the first window shouldnt have shadow until a new window have spawned/moved. Does it work like that for you too?

[ikz87]

Here's a new recording with the latest version.
The behavior is still the same, and as you can see, shadows appear as soon as I change the setting.

2023-02-04.19-08-01.mp4

Here's the log generated in the video: picom.log
Let me know if you need anything else

[FT-Labs]

I'm not sure why this happens, for example it happens before the patch it used to happen when my charger is not plugged. I think it is because animations try to start while glx shaders are not properly loaded, because this only happens when it is started, not while it is on. In my computer, amdgpu with nvidia disabled it works correct now. i will try to check it with an older intel cpu laptop.

[FT-Labs]

This should be fixed now, can someone try?

[ikz87]

Overall performance is way better now, that's nice to see c:
However, this issue still persists

2023-11-23.22-17-03.mp4