terminals in floating scratchpads lose transparency after restarting i3

[ghost]

Platform

archlinux, fully up to date

GPU, drivers, and screen setup

intel uhd 620, xf86-video-intel v1:2.99.917+899+gf66d3954-1

Environment

i3 (without gaps)

picom version

v7.5

Configuration:

mark-ovredir-focused = true;
shadow = true;
no-dock-shadow = true;
no-dnd-shadow = true; 
clear-shadow = true;
shadow-radius = 5;
shadow-offset-x = -5;
shadow-offset-y = -5;
shadow-ignore-shaped = true;
detect-client-leader = false;

Steps of reproduction

1. open a terminal in a floating scratchpad, the terminal may be either urxvtc or alacritty, i didn't test with others, but i think it happens in any terminal
2. restart i3 with mod+shift+r

Expected behavior

Current Behavior

the window is no longer transparent and there is a trail behind last entered symbol

Stack trace

Other details

herre's a video https://vimeo.com/384925512

[ghost]

sometimes it happens to regular windows too (as opposed to floating scratchpads)

[ghost]

this is the log when picom is ran from a terminal and i restart i3

[ 01/15/2020 06:18:38.326 x_create_picture_with_pictfmt_and_pixmap ERROR ] failed to create picture
[ 01/15/2020 06:18:38.327 paint_one ERROR ] Window 0x0160002d is missing painting data.

also i just noticed that a config does not matter

[ghost]

i found this #284, but it doesn't seem like my case. i set my wallpaper with feh

[yshui]

This might be an i3 bug.

Please run this command:

xwininfo -id $(xwininfo -children | awk '/Parent/ { print $4; }')

, click on the window which has lost its transparency, then post the output here.

[ghost]

@yshui

 ~ xwininfo -id $(xwininfo -children | awk '/Parent/ { print $4; }')

xwininfo: Window id: 0x140005a "[i3 con] container around 0x55dec898cb80"

  Absolute upper-left X:  1174
  Absolute upper-left Y:  547
  Relative upper-left X:  1174
  Relative upper-left Y:  547
  Width: 648
  Height: 488
  Depth: 32
  Visual: 0x8f
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x1400000 (not installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: yes
  Corners:  +1174+547  -98+547  -98-45  +1174-45
  -geometry 648x488-98-45

[yshui]

Thanks.

does reapplying the wallpaper fix your problem?

[ghost]

no

[yshui]

OK.

I need more information to figure out what this is. Can you capture an apitrace?

[ghost]

okay so here's what it outputed into stdin

 ~ apitrace trace --api gl /usr/bin/picom
apitrace: loaded into /usr/bin/apitrace
apitrace: unloaded from /usr/bin/apitrace
apitrace: loaded into /usr/bin/picom
[ 01/17/2020 23:26:07.239 parse_config_libconfig WARN ] Option `no-dock-shadow` is deprecated, and will be removed. Please use the wintype option `shadow` of `dock` instead.
[ 01/17/2020 23:26:07.239 parse_config_libconfig WARN ] Option `no-dnd-shadow` is deprecated, and will be removed. Please use the wintype option `shadow` of `dnd` instead.
[ 01/17/2020 23:26:07.239 parse_config_libconfig WARN ] "clear-shadow" is removed as an option, and is always enabled now. Consider removing it from your config file
apitrace: tracing to /home/tho/picom.trace
[ 01/17/2020 23:26:15.230 x_create_picture_with_pictfmt_and_pixmap ERROR ] failed to create picture
[ 01/17/2020 23:26:15.231 paint_one ERROR ] Window 0x01200058 is missing painting data.
^Capitrace: unloaded from /usr/bin/picom
zsh: segmentation fault (core dumped)  apitrace trace --api gl /usr/bin/picom

and
and this is the log picom.trace.txt

[ghost]

btw this issue wasn't an issue when i used old compton. (i'm on arch)

[xzfc]

I can reproduce a similar problem with this minimal example:

0. Install peek. Although, any other RGBA app would suffice, I think.

1. Run i3 with this config in Xephyr:

$ Xephyr :10
$ unset I3SOCK; DISPLAY=:10 i3 -c i3-config.txt

2. You should see the peek window with a transparent border. img1.png

3. Press F1 to restart i3, then move the peek window around. I see the trail: img2.png

i3 version: 4.16, 4.17.1, 4.18.
picom version: v7.5.
I can't reproduce it on xcompmgr v1.1.8.

[yshui]

@xzfc Can you check if this has been fixed in the latest next branch?

[xzfc]

@yshui No, same result.

$ picom --version
vgit-85086

[yshui]

@xzfc I cannot reproduce this locally. Also you are on a commit that does not exist in this repo?

[xzfc]

I'm on 85086bc.

[yshui]

@xzfc Ah, sorry.

Can you attach your picom configuration?

[yshui]

@xzfc Did you meant to have --experimental-backends in the i3-config.txt you sent?

[yshui]

Never mind, I figured it out.

[xzfc]

Can you attach your picom configuration?

I have no picom configuration.

[yshui]

No problem.

I think this is not a problem in the new backends as long as you have a wallpaper, and I will fix the no wallpaper case. Something odd is going on in the old backends, so I will be looking into it.

[xzfc]

It's still reproducible with picom --experimental-backends and wallpaper set by feh --no-fehbg --bg-fill ….

[yshui]

Do you have a screenshot? Because I tried that and didn't see any problem.

[xzfc]

img3.png

[yshui]

This is very odd, I cannot make it happen on my computer. I believe I am doing the exact same thing as you.

I am using your i3-config.txt, and running picom with picom --experimental-backends --config /dev/null.

Edit: oops, never mind. it's happening now.

[xzfc]

I've bisected it to the first bad commit: 426043b.

[xzfc]

I think I've found the root of the problem. See how window hierarchy is changed during the i3 restart process:

1. root -> frame1 -> peek (before the restart)
2. root -> peek
   Right before the restart, i3 destroys the frame window and remaps the client window to root.
3. root -> frame2 -> placeholder
   After restart occurs, i3 creates a frame containing a temporary placeholder window.
4. root -> frame2 -> peek
   Then, i3 replaces the placeholder window by an actual client window. The frame window remains the same. (it is called "swallowing" in i3 documentation)

And seems picom¹ doesn't handle transition 3→4 well. It still thinks that frame2 contains placeholder and doesn't know that it is destroyed and replaced by peek.

¹ as of the first bad commit 426043b

[yshui]

@xzfc That's a very good observation. That helps a lot, thanks.

[yshui]

Apparently picom is only listen for reparent-to-root and reparent-from-root events, and is thus not getting any reparent events like the ones generated in step 4.

[yshui]

I think we had this problem since the compton days.

[yshui]

@xzfc I think I fixed this in next, can you try it? Although I might have introduced new bugs while fixing this...

[yshui]

TODO: add a testcase for this issue

[xzfc]

It still happens, although it's not every time. It's rare (~1/20) if there is only one window on the workspace, but it's more often if there are multiple windows.

To reproduce, open 4 peek windows and press F1 repeatedly until you'll see artifacts inside any window. Then, if you move the window with artifacts, you'll see the trail.

Screenshots: without-artifacts.png with-artifacts.png

Also, there is a minor issue: after the restart (assuming there is no trail), the border is not transparent until you move the window.

[yshui]

Ah, this is very annoying 😢 Looks like a bug dependent on in what order things happen. At least we are going the right direction.

[yshui]

I think I know

Things happen in this order:

1. reparent placeholder to frame
2. map frame
3. destroy placeholder

picom only starts to listen for child destroy event after 2. So if we received/handled the MapNotify too late, we won't get the DestroyNotify for the placeholder, and thing will break.

[yshui]

And there is no guaranteed way to do this "fast enough". The moment we learn about the frame window, step 1-3 could have all happened. Looks like we need a different strategy.

[yshui]

i am terribly sorry. stupid github

[yshui]

I have an automated test script in place to reproduce it. I have a tentative fix in place, but this issue is still reproducible ~2% of the time.

[yshui]

@xzfc Should've been fixed in next now.

[xzfc]

Thank you.

[mark-jordanovic-lewis]

I am having the same issue on all transparent windows on Manjaro i3. It's just a QoL issue.
Apologies. Simply running picom sorts the windows correctly.