Closing Window Animation leaves artifacts.

[Moshe-Shelomov]

When I switch workspaces, randomly appears a little square on the screen (sometimes more than one).
if I switch back and forth it eventually disappears but it's quite irritating.
Visually it appears as if programs are zooming out but instead of disappearing they are oddly minimized

I use EndeavourOS and Qtile
Let me know if I need to provide any further info

in the attached zip is my picom config and screen recording showing the glitch

Archive.zip

[allusive-dev]

Hello Moshe!
I am sorry this is happening to you, I personally haven't experienced this before but I will try my best to assist.

After using your config I cannot seem to replicate this issue.
My Specs:
Arch Linux
NVIDIA RTX 3060 (nvidia-open)
Intel i5-12600
*Xmonad

Would you be able to share your hardware specs as well as what graphics driver you are using along with your monitor resolutions.

[Moshe-Shelomov]

Hello Moshe! I am sorry this is happening to you, I personally haven't experienced this before but I will try my best to assist.

After using your config I cannot seem to replicate this issue. My Specs: Arch Linux NVIDIA RTX 3060 (nvidia-open) Intel i5-12600 *Xmonad

Would you be able to share your hardware specs as well as what graphics driver you are using along with your monitor resolutions.

I'm on a Alienware (Dell) laptop , model: "17 R3"
CPU - Intel i7 6700HQ
GPU - Nvidia 970M (nvidia-dkms driver from AUR)
resolution - 1920*1080
Kernel: 6.5.3-zen1-1-zen

since it's a laptop, I'm also using "optimus manager" for switching graphics
(https://github.com/Askannz/optimus-manager)

[allusive-dev]

My first observation is that you have not set a window-unmap animation in your configuration. Try setting it to zoom or check the wiki's animations page.
I have an older nvidia laptop with amd iGPU so I could maybe try installing endeavourOs and testing it at some point if necessary.

My other guess is that it could be your graphics driver. I know that the proprietary nvidia driver causes quite a couple of odd issues for picom and this could be one of them. So if you are able to, one suggestion might be disabling your iGPU from bios, not using optimus-manager and installing the nvidia-open package. (I have done this on my own system to fix conflicts with my iGPU)
The above option is sort of a last resort considering the bios changes.

A few other questions.
Does the black box appear for all windows or only affect some?
If the box appears for all windows then does the color of the box reflect the coloring of the window causing it?

[Moshe-Shelomov]

From my observation, the box appears for any window (I can attest to it appearing regularly from the programs that I use all the time: konsole, librewolf,telegram, dolphin and okular)
and it does reflect the color of the window
So when it is caused by librewolf for example, it has the color of the current page opened in it, etc.

[Moshe-Shelomov]

I've just added to my config the following lines:

animation-for-open-window = "zoom";
animation-for-unmap-window = "zoom";
animation-for-workspace-switch-in = "zoom";
animation-for-workspace-switch-out = "zoom";
animation-for-transient-window = "zoom";

...but the glitch is still there.
Additionally, I can confirm that KeepassXC leaves a square as well

Since in the wiki you wrote that it's unnkown what "animation-clamping" does, I tried switching it to true, however it didn't help

I've also tried using a different animation, namely: "slide-up" for all of the actions. After doing so, instead of squares the windows now leave a line at the top of the current window (or where the top would be, if switched to an empty workspace, as shown in the attached screenshot)

[draculalaa]

Same problem to me, and if I change workspace switch animation style from zoom to "slide-", it appears to be a slender rectangle, rather than a little square remains on the screen. @Moshe-Shelomov same as you mentioned above.

I belive it's not caused by graphic driver, since I'm using a laptop with AMD 6800H and integrated graphics.

And another problem is when I switch the workspace slowly (after the animation is fully played I think) , the last focused window's image will stay in new workspace.

Seems like all above are caused by same reason. I think they are related to WM's behavior, but my poor searching skill find nothing about that.

OS: Arch Linux x86_64
WM: bspwm
CPU: AMD Ryzen 7 6800H (16) @ 4.785 GHz
GPU: AMD Radeon 680M

vid.zip
picom.conf.txt

[allusive-dev]

Hey @draculalaa and @Moshe-Shelomov.
Thank you very muhc for your contributions to helping solve this issue.
From what I can tell, windows that have been closed after being moved to a new workspace they leave "residue" in different patterns depending on which unmap animation is set.

My first idea would be to recode the unmap animation slightly however this doesn't make sense since I and others do not experience this issue.

I agree with you now @draculalaa about it not being a graphics driver issue. Considering 2 different people with different GPU's are experiencing the issue it must be something deeper.

I am going to do some research and get back to you both asap.
Thank you for your patience and I hope we can resolve this!

[allusive-dev]

vid.zip

This video that you sent is quite odd. The shaping of the window residue is extremely odd and not logical to the unmap animation.
Another thing to figure out I guess.

[allusive-dev]

To help diagnose the issue can both @draculalaa and @Moshe-Shelomov try using this picom config and tell me whether the issue is still present.
Thanks again!

picom.conf.txt

picom --config "$(pwd)/Downloads/picom.conf.txt"

Or wherever the downloaded file is on your system.

[Moshe-Shelomov]

yes, the issue remains with this config as well

[Moshe-Shelomov]

I switched to qtile just a few days ago and before that I was using i3, so I've decided to check whether this issue will appear there as well. After playing around with windows and workspaces and whatever in i3, there was no issue whatsoever.(with my picom config)
Both zoom and slide animations work as expected without glitches

Perhaps there's something in my qtile config that is causing the issue, or there might be some incompatibility with qtile in general?

[allusive-dev]

Hello @Moshe-Shelomov
Yeah well considering that the config I sent you did not fix it but you also had no issues on another WM. My best guess like you said is something to do with your WM/wm config.
I haven't used qtile before but I am surprised since it is basically just xmonad in python.

[allusive-dev]

Considering what @draculalaa said this issue may also extend to bspwm. However I can't be sure of this at the moment until they.

1. Try the config i sent
2. Try a different WM

[draculalaa]

Hi,

1. I've tried the config file @allusive-dev provided above and problem remains.
2. And I tried i3wm with basically default config, there is no animation glitch as far as I can test.

Further more I tried to install pijulius/picom manually from source, and in bspwm the problem seems actually same to this repo. So it's just not very suitable for bspwm I guess, or it conflicts with some of my configurations in bspwm, or something else.

Just wondering why I can't find anyone discussed these issues, since I've seen several bspwm rice choose pijulius' picom.

[allusive-dev]

Thanks for trying that out.
You shouldn't experience any differences between this repo and pijulius (the difference between this repo and pijulius can be found here)

I don't think the issue is directly with bspwn or qtile but possibly with your configurations of these WM's, considering that it doesn't seem to be a graphics issue.

My only suggestion now is that you both debug your WM configs by either testing if the issue is present on a fresh config or analyzing your code line by line.

[Poyso]

I have the same issue, and i run EndavourOS with qtile and running the "original" picom-pijulius

[allusive-dev]

I have the same issue, and i run EndavourOS with qtile and running the "original" picom-pijulius

Thanks for hopping in. At the moment we think the issue may be to do with your user configuration of qtile/bspwm since others have used these WM without issues with picom/pijulius.

You shouldn't experience any differences between this repo and pijulius (the difference between this repo and pijulius can be found here)

[Poyso]

Now i have tried qtile with the default config + the autostart.sh and still returns this problem.

The only thing i noticed,it never happened until i switched between work space (so for me moving the windows to monitor 1 to monitor 2), but might be this behaviour happened even before not sure.

[allusive-dev]

At the moment my guess is that this may be an issue with qtile and or bspwm. I am thinking this because of an issue i recently reviewed which has revealed that workspace switching animation do not play specifically on dwm

Unfortunately there is not a lot I can do about this if it is a issue with the WM itself.
But if any other information comes up suggesting otherwise then I hope to be able to try to fix it.

[AsharAlvany]

I wanted to comment since I was experiencing the ghost artifacts, as well. I'm also on qtile. From my testing, I was able to get rid of the artifact by turning off shadows. I hope that helps some!

[allusive-dev]

Thank you for that. I would close it at that but some have tested with the default config which would be without shadows.

Anyone is welcome to try turning off shadows and let us know how it goes but I'm not sure if that is the issue.

[vinivosh]

Can confirm, I am getting these artifacts too with BSPWM and shadows completely turned off.

I also get some weird animations freaking out when I change workspaces. Seems to happen more frequently when I change workspaces after a period of time of not changing them (like > 5 minutes). Instead of animations playing properly once they play out like five times really quickly and sometimes not even using the animation I had configured in picom.conf but random ones instead. Pure chaos.

I'm lauching with picom -b --experimental-backends --backend glx by the way, if that's relevant.

An idea: can anyone using BSPWM and not getting these issues share their picom.conf and bspwmrc files? So we can test them out.

[allusive-dev]

I'm lauching with picom -b --experimental-backends --backend glx by the way, if that's relevant.

From what i can see looking at the source code, experimental backends should only be used if you know what your doing. I would list what experimental-backend does but basically.

If you are not using dual-kawase blur or are debugging then do not use it.

An idea: can anyone using BSPWM and not getting these issues share their picom.conf and bspwmrc files? So we can test them out.

I agree with this.

[vinivosh]

If you are not using dual-kawase blur or are debugging then do not use it.

I am indeed using the dual-kawase blur, that's why I'm "stuck" with --experimental-backends. It's just so beautiful, haha 😅. A shame that I can't use rounded corners with it…

By the way, I seem to have been able to fix the bug of animations freaking out by setting animation-clamping to true in the configs. Something about the windows getting bigger than their final size during the animation (and sometimes even parts of them appearing for a brief moment in my other monitor) seems to be what was causing the issue. Much more usable now!

The artifacts for unmapped windows still happens, unfortunately. I thought they had been fixed, because I didn't see any for some 20 minutes of use. But after rebooting the next day they all came back. I did change kernels (linux-zen to linux) between these reboots, though. I will try again with linux-zen later today to see if anything changes.

[allusive-dev]

I am indeed using the dual-kawase blur, that's why I'm "stuck" with --experimental-backends. It's just so beautiful, haha 😅. A shame that I can't use rounded corners with it…

Wait you can't use rounded corners with that? I am going to test that because that is pretty important.

Yeah i actually found that my animations go insane on XMonad very rarely when i don't use animation-clamping.

I did change kernels (linux-zen to linux) between these reboots, though. I will try again with linux-zen later today to see if anything changes.

I wouldn't know if changing kernels would do anything but let me know if it does.

[allusive-dev]

"Rounded corners is only supported on legacy backends"...

Welp. That is something I definitely have to fix.
I'll give it a go today and let you know how i do.

[allusive-dev]

Well bad news.
The support for rounded corners is actually not supported in experimental backends and just removing the reset code for the corners does not fix the issue.
I will keep playing with it but I don't know a ton about backends.

[allusive-dev]

Hello Everyone,
I wanted to check back in and see if anymore progress has been made and if the issue has been isolated anymore than to a issue with qtile/bspwm?

[xyzbtw]

I had the same issue while using openbox, but it got resolved by disabling rounded corners

[vinivosh]

I'm going to try this with AwesomeWM tomorrow and see how it goes.

[SolninjaA]

I can confirm this also happens on XMonad. It seemed to go away after I open another window, but now that I've switched workspaces and various other things the artifact is always present in the desktop background layer.

Please note, this only happens to me when window borders are enabled. Otherwise, this doesn't happen.

[allusive-dev]

Thanks @SolninjaA
What I can tell is exactly what you said, the issue only seems to happen to people using window borders.

I'm looking at updating picom to the latest upstream version soon, But that may take quite a while so sit tight everyone!

[SolninjaA]

Ok, great! It would be great to have picom-allusive on the latest upstream version. I did some testing and you can use "dual-kawase" blur with rounded corners on the upstream version. I'm mentioning that because I noticed that @vinivosh was talking about that.

I haven't tested to see if the artifacts problem is also a problem on the upstream version, but my guess would be no.

[rudyon]

on bspw and have this issue aswell

[allusive-dev]

on bspw and have this issue aswell

Can I ask whether you are using window borders or not?

[allusive-dev]

Hey @vinivosh
Continuing from what I was saying about hopefully fixing the issue with dual-kawase only being avaliable on experimental-backends which doesn't have rounded-corners.

This issue has been and will be fixed in the update to yshui/picom-10.2.
The update is live now as v1.0.0

For everyone. I am hoping that once the update is complete this artifacts issue will be resolved but that is yet to be seen.
Thank you all for your patience!

[rudyon]

on bspw and have this issue aswell

Can I ask whether you are using window borders or not?

i was. after disabling window borders it does go away

[allusive-dev]

@vinivosh @rudyon @AsharAlvany @Poyso @xyzbtw @draculalaa @Moshe-Shelomov

Everyone, this has been tested by @SolninjaA on v1.2.1 and they let me know that the issue is now resolved!

If anyone has any more problems to do with this issue please let me know.

[vinivosh]

That's really great! The issue seems to be indeed resolved 👏

However, the dual-kawase blur seems to not be working anymore… am I doing something wrong in the config?

blur: {
  # requires: https://github.com/ibhagwan/picom
  method = "dual_kawase";
  # method = "kernel";
  strength = 8;
  deviation =1.0;
  # kernel = "11x11gaussian";
  background = false;
  background-frame = false;
  background-fixed = false;
  kern = "3x3box";
}

[allusive-dev]

That's really great! The issue seems to be indeed resolved 👏

However, the dual-kawase blur seems to not be working anymore… am I doing something wrong in the config?

blur: {
  # requires: https://github.com/ibhagwan/picom
  method = "dual_kawase";
  # method = "kernel";
  strength = 8;
  deviation =1.0;
  # kernel = "11x11gaussian";
  background = false;
  background-frame = false;
  background-fixed = false;
  kern = "3x3box";
}

@vinivosh Please take a look at the this page of the wiki which explains the changes made to blur as of 1.0

Someone else opened a issue for the same reason here #11

[vinivosh]

@allusive-dev Ooh, thanks, didn't see the changes in the wiki, my bad.

I like the idea of using a whitelist for blurred windows, much better on performance.

Which makes me think: could we have a whitelist for transparent windows too? I notice some context menus are quite transparent in my setup, even though I never configured anything that resambles that behaviour. (Maybe having both options, blacklisting and whitelisting would be preferable in this case)

[allusive-dev]

Which makes me think: could we have a whitelist for transparent windows too? I notice some context menus are quite transparent in my setup, even though I never configured anything that resambles that behaviour. (Maybe having both options, blacklisting and whitelisting would be preferable in this case)

I'm a bit confused. Doesn't opacity-rule already fill that requirement?

[vinivosh]

Sounds like it should, but still I see a lot of context menus being made transparent without any explicit rule.

For example:

The discord context menu (I couldn't make flameshot take a screenshot while the right-click menu was open, but I could with this "hover tip", which has the same behaviour)

The LibreWolf (Firefox fork) right-click context menu

My opacity rules config:

# Specify a list of opacity rules, in the format `PERCENT:PATTERN`,
opacity-rule = [
  "70:class_g = 'Xfce4-terminal'",
  "70:class_g = 'kitty'",
  "70:class_g = 'XTerm'",
  "70:class_g = 'xterm'",
  "70:class_g = 'UXTerm'",
  "80:class_g = 'SpeedCrunch'",
  "80:class_g = 'Rofi'",
  # "100:class_g = 'LibreWolf'",
  # "100:class_g = 'Firefox'",
  # "100:class_g = 'Chrome'"
];

[allusive-dev]

I have a suspicion. @vinivosh
This sounds like a win-types problem possibly.

If you have a win-types config setup please attach it.

If not try this at the bottom of your config. I'm not sure which one equals what window so I just set them all lol.

wintypes:
{
  normal = { opacity = 1; };
  menu = { opacity = 1; };
  tooltip = { opacity = 1; };
  dock = { opacity = 1; };
  dnd = { opacity = 1; };
  popup_menu = { opacity = 1; };
  utility = { opacity = 1; };
  toolbar = { opacity = 1; };
  notification = { opacity = 1; }
};

[allusive-dev]

Let's move to a new issue. #15

[allusive-dev]

For Anyone coming here in the future. This issue was resolved as of update 1.2
Using any version that matches 1.2 or newer than that will resolve the issue.