FT-Labs / picom

More than 10 unique animation supported picom fork (open window, tag change, fading ...)
Other
248 stars 32 forks source link

Monocle layout is buggy with shadows on #17

Open ikz87 opened 1 year ago

ikz87 commented 1 year ago

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:

https://user-images.githubusercontent.com/98569017/215165745-2fa8f246-5e02-4241-a87e-a5f616823574.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 commented 1 year ago

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 commented 1 year ago

You can find my config here

FT-Labs commented 1 year ago

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

How about this one?

https://github.com/FT-Labs/picom/commit/157ecd2077e538e0b1e66d47ffbe5d771fb40cf8

D3SK3R commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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?

https://github.com/FT-Labs/picom/commit/90f57e9b1a9bb5bed8bf0f190652287708a1cfe0

ikz87 commented 1 year ago

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

FT-Labs commented 1 year ago

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 commented 1 year ago

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.

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

FT-Labs commented 1 year ago

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 commented 11 months ago

This should be fixed now, can someone try?

ikz87 commented 11 months ago

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

https://github.com/FT-Labs/picom/assets/98569017/ff77163c-3f1f-4224-8d98-d2cbe45a3003