Picom not fading while the window is being closed

[samokosik]

Platform

Newest Arch install. LTS kernel - 5.4.91-1-lts

GPU, drivers, and screen setup

NVidia Quadro m1000m, nvidia-lts drivers, 1 monitor.

Environment

I use picom with i3-gaps. Remember that I use experimental backends version

picom version

Picom version: vgit-d9743 command ran: picom --version

Configuration:

Link: https://github.com/samokosik/setup/blob/main/picomconfig

The Important part:

# Fade windows in/out when opening/closing and when opacity changes,
#  unless no-fading-openclose is used.
# fading = false
fading = true;

# Opacity change between steps while fading in. (0.01 - 1.0, defaults to 0.028)
# fade-in-step = 0.028
fade-in-step = 0.028;

# Opacity change between steps while fading out. (0.01 - 1.0, defaults to 0.03)
# fade-out-step = 0.03
fade-out-step = 0.03;

# The time between steps in fade step, in milliseconds. (> 0, defaults to 10)
# fade-delta = 5

# Specify a list of conditions of windows that should not be faded.
# fade-exclude = []

# Do not fade on window open/close.
# no-fading-openclose = false

# Do not fade destroyed ARGB windows with WM frame. Workaround of bugs in Openbox, Fluxbox, etc.
# no-fading-destroyed-argb = false

Steps of reproduction

1. Set picom experimental version to a configuration with fading.
2. Try opening a window (you will see sth like an animation - picom will fade the opening)
3. Then close and picom will not make a nice animation (fading) as it made during opening.

Expected behavior

What I should see is a fading during the window closing as well. it should be similar to fading when window is opening.

Current Behavior

When I close the window, no fading is there. Behaves the same way as with fading tuned off.

Stack trace

Other details

Not my setup: https://preview.redd.it/7n3qj3wtbp151.gif?format=mp4&s=eca8016ea26f1daa392985feab830472925fdde5

The problem is visible, though. Fading when the window is closing is not there.

[kwand]

I seem to have the same issue, so I can corroborate on this issue whenever this is further investigated into. (I just discovered your issue here; always been wondering why it seemed like closing windows seemed faster than opening them, with fading turned on).

I'm also using an NVIDIA card (RTX 2080) with i3-gaps on the experimental backends.

[yshui]

Can someone paste a --log-level=debug log file?

[rojnwa]

Can someone paste a --log-level=debug log file?

I have the same problem. For testing purposes with --log-level=debug I opened a terminal (Alacritty) and closed it again.

Debug file: https://haste.zneix.eu/afiqanudub (the first 1.1k lines can be more or less ignored - Alacritty first appearance: line 1188) picom.conf: https://haste.zneix.eu/unojuqoroc

[rojnwa]

Any updates on this @yshui?

[georglauterbach]

Same issue, fade-in looks about right, fade out does not work.

Started picom with higher log level: https://pastebin.com/ss8ecYWC. Opened a terminal emulator, closed it and repeated.

System: Ubuntu 21.10 (Impish Indri) with Linux kernel 5.13.0-22-generic DE: Regolith Linux with GNOME 40.4.0 WM: i3 (-gaps) 4.19.1 (2021-02-01)

picom version vgit-31e58 picom config: https://pastebin.com/3kLWNgns

[jepvini]

I have the same issue... There is any known solution?

[kwand]

@yshui Just to add some (what I hope is relevant) information, I have a suspicion that this is a DE/WM-related issue.

I've since switched over to using awesomewm (git-version) as my daily-driver window manager, and I'm getting the proper fading effects whenever I (open and) close windows.

Perhaps something is wrong upstream, or we need a different way of detecting i3wm closing windows?

(BTW, I confirmed this with setting fade-delta to a high value i.e. fade-delta = 30, so it's not my eyes mistaking some other effect for fading while closing. Not sure if this is just i3wm or if it also affects other WMs, but at least awesome does not seem to suffer from this problem)

[tryone144]

I think this is related to https://github.com/yshui/picom/issues/704.

I've done some testing on my own and compared the picom debug-logs in i3 with awesome. This suggests it might be caused by the way i3 destroys of windows and its frames — and picom seems to have struggled with i3's window management in the past. (awesome log for comparison.)

i3's destroyed windows are not rendered, because they have no client window (client_win = XCB_NONE) but are not yet updated to reflect that change in picom's internal state. The following check against the debug_window (which is XCB_NONE in normal operation) prevents the window from being drawn.

diff --git a/src/picom.c b/src/picom.c
index 81fb334..4e0c3f8 100644
--- a/src/picom.c
+++ b/src/picom.c
@@ -706,8 +706,9 @@ static struct managed_win *paint_preprocess(session_t *ps, bool *fade_running) {
                // pixmap is gone (for example due to a ConfigureNotify), or when it's
                // excluded
                if (w->state == WSTATE_UNMAPPED ||
-                   unlikely(w->base.id == ps->debug_window ||
-                            w->client_win == ps->debug_window)) {
+                   unlikely(ps->debug_window != XCB_NONE &&
+                            unlikely(w->base.id == ps->debug_window ||
+                                     w->client_win == ps->debug_window))) {
                        to_paint = false;
                } else if (!w->ever_damaged && w->state != WSTATE_UNMAPPING &&
                           w->state != WSTATE_DESTROYING) {

i3 destroys the client win and immediately the frame window, whereas awesome destroys the client win, picom updates the frame window to be its own client ("client self (override-redirected)") and then destroys the frame window 20ms later.

Having said that, the above patch does not completely fix the fade-out issue in i3. With the patch applied, you can see i3's frame window fading out, but the original client window disappears in an instant. While on the other hand, now windows with no client window are rendered, which might not be what we want.