Picom: Stacked Windows disappear on i3 restart

[jrwrigh]

Platform

Manjaro i3 19.0.2

GPU, drivers, and screen setup

Note: This issue occurs on two different computers running the same OS, but different hardware and drivers (one open-source, the other proprietary). I'll give specs for one machine for now.

iGPU and dGPU laptop, using a build in screen and external monitor via HDMI port.

➜ inxi -G
Graphics:  Device-1: Intel 4th Gen Core Processor Integrated Graphics driver: i915 v: kernel 
           Device-2: NVIDIA GK107GLM [Quadro K1100M] driver: nouveau v: kernel 
           Display: x11 server: X.Org 1.20.7 driver: intel,nouveau unloaded: modesetting 
           resolution: 1920x1080~60Hz, 1920x1080~60Hz 
           OpenGL: renderer: Mesa DRI Intel Haswell Mobile v: 4.5 Mesa 19.3.5 

```
➜ mhwd -li

> Installed PCI configs:

NAME VERSION FREEDRIVER TYPE

       video-linux            2018.05.04                true            PCI

➜ glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) Haswell Mobile (0x416)
Version: 19.3.5
Accelerated: yes
Video memory: 1536MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.3.5
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 19.3.5
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 19.3.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

### Environment
i3 with gaps (I think?), picom launched within the i3 config:
```i3
....
exec --no-startup-id pkill picom; nitrogen --restore; sleep 1; picom -b
...

picom version

picom --version: v7.5

➜ picom --diagnostics
[ 03/24/2020 13:41:49.003 register_cm FATAL ERROR ] Another composite manager is already running

Configuration:

Blob to dotfiles repository (it's really long).

Steps of reproduction

1. Stack windows
2. Restart i3
3. (Optional) Restart picom (only need to to that on one of my computers for some reason)
4. The initially visible window is still visible, but the hidden (stacked) windows are not visible

Expected behavior

For the screens to maintain their correct transparency

Current Behavior

Other details

I think what's probably happening is that the opacity rule I have setup for hidden windows (of which stacked windows are) is breaking when i3 reloads:

opacity-rule = [
  "0:_NET_WM_STATE@:32a *= '_NET_WM_STATE_HIDDEN'",
....
]

Thus picom doesn't know to turn the opacity back to normal for the hidden windows.

[valeriangalliat]

I've had the same issue, this comment on Reddit gives a workaround that worked for me!

Unfortunately if you restart i3 in place with a tabbed or stacked arrangement some can be bugged and stay 100% transparent. The solution is to restart i3 then compton then enumerate all windows with wmctrl -l and for each window id run

xprop -id $id -remove _NET_WM_WINDOW_OPACITY

I made a shell script based on that that I call i3-picom-restart (I'm using xprop -root instead of wmctrl -l to list all windows):

#!/bin/sh -e
#
# Reload i3 and Picom, fixing the transparency bug with transparent windows in
# stacked/tabbed layouts that would otherwise stay transparent forever.
#
# See <https://www.reddit.com/r/i3wm/comments/cqtu6t/i3_transparency/ex0v4hp/>.
#
i3-msg restart
killall -USR1 picom

xprop -root | grep '_NET_CLIENT_LIST(WINDOW)' | grep -o '0x[0-9a-zA-Z]*' \
    | xargs -I{} xprop -id {} -remove _NET_WM_WINDOW_OPACITY

And in my i3 config I replaced bindsym $mod+Shift+r restart with bindsym $mod+Shift+r exec i3-picom-restart

[yshui]

Duplicate of #134. Should have already been fixed in the next branch