Terminals with opacity causes tiny, not fitting recordings

[carrascomj]

Describe the bug
The output produced with t-rec is a very small portion of the window on xmonad.

Using t-rec -l gives me a 10x10 for each window open in the workspace.

Window | Id
 (10x10) | 4194662

To Reproduce
Steps to reproduce the behavior:

1. Install xmonad.
2. Install t-rec.
3. Open a terminal and run t-rec
4. Watch the output

Expected behavior
The whole window, with borders.

Screenshots

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Version [e.g. 22]

Additional context
Another tiling window manager (leftwm) and another terminal (xcfe4-terminal) produced the same behavior.

System details

OS: ArcoLinux
Kernel: 5.9.14-arch1-1
DE: xmonad
Terminal: alacritty
CPU: Intel i7-8750H (12) @ 2.200GHz
GPU: NVIDIA GeForce GTX 1050 Mobile
Xserver: 1.20.10-3

[sassman]

Could you please also run xwininfo -root -tree -int and provide the output here? (you could also limit it to the root window down to the shell you running t-rec from)

[carrascomj]

Only the terminal open, this is what I get:

xwininfo -root -tree -int

Output

xwininfo: Window id: 581 (the root window) (has no name)

Root window id: 581 (the root window) (has no name)
Parent window id: 0 (none)
20 children:
4196292 (has no name): () 10x10+1905+1065 +1905+1065
35651584 (has no name): () 1x1+0+0 +0+0
33554432 (has no name): () 1x1+0+0 +0+0
31457280 (has no name): () 1x1+0+0 +0+0
29360128 (has no name): () 1x1+0+0 +0+0
27262978 "georg@barry:~": ("Alacritty" "Alacritty") 1896x1026+10+40 +10+40
8388611 (has no name): () 1x1+-1+-1 +-1+-1
16777224 (has no name): () 1x1+-1+-1 +-1+-1
20971528 (has no name): () 1x1+-1+-1 +-1+-1
18874376 (has no name): () 1x1+-1+-1 +-1+-1
25165829 "Polybar tray window": ("tray" "Polybar") 80x30+1840+0 +1840+0
3 children:
18874379 "pamac-tray": ("pamac-tray" "Pamac-tray") 16x16+8+7 +1848+7
1 child:
18874380 (has no name): () 1x1+-1+-1 +1847+6
16777227 "NetworkManager Applet": ("nm-applet" "Nm-applet") 16x16+32+7 +1872+7
1 child:
16777228 (has no name): () 1x1+-1+-1 +1871+6
20971531 "blueberry-tray.py": ("blueberry-tray.py" "Blueberry-tray.py") 16x16+56+7 +1896+7
1 child:
20971532 (has no name): () 1x1+-1+-1 +1895+6
25165825 "polybar-mainbar0_eDP-1-1": ("polybar" "Polybar") 1920x30+0+0 +0+0
20971521 "blueberry-tray.py": ("blueberry-tray.py" "") 10x10+10+10 +10+10
8388609 "xfce4-notifyd": ("xfce4-notifyd" "Xfce4-notifyd") 10x10+10+10 +10+10
18874369 "pamac-tray": ("pamac-tray" "Pamac-tray") 10x10+10+10 +10+10
16777217 "NetworkManager Applet": ("nm-applet" "Nm-applet") 10x10+10+10 +10+10
14680065 "xfce4-power-manager": ("xfce4-power-manager" "Xfce4-power-manager") 10x10+10+10 +10+10
12582913 "polkit-gnome-authentication-agent-1": ("polkit-gnome-authentication-agent-1" "Polkit-gnome-authentication-agent-1") 10x10+10+10 +10+10
10485764 "picom": ("picom" "picom") 1x1+0+0 +0+0
4194305 "LG3D": () 1x1+-100+-100 +-100+-100

[sassman]

Thanks, could you just for curiosity try to run t-rec this way:

# running t-rec with specify the most parent alacrity terminal window id
WINDOWID=27262978 t-rec

[carrascomj]

Nein, that does not work, either :(.

[sassman]

😭 - ok was a try. I'm trying to reproduce it and come up with a fix soon.

[carrascomj]

It might be important that the output of t-rec -l does not list any of the windows named with Alacritty (or any other named window). For instance, with three terminals open:

xwininfo -root -tree -int

Output

xwininfo: Window id: 581 (the root window) (has no name)

Root window id: 581 (the root window) (has no name)
Parent window id: 0 (none)
32 children:
4196662 (has no name): () 10x10+1905+1065 +1905+1065
4196657 (has no name): () 10x10+1905+545 +1905+545
4196652 (has no name): () 10x10+950+1065 +950+1065
71303168 (has no name): () 1x1+0+0 +0+0
69206016 (has no name): () 1x1+0+0 +0+0
67108864 (has no name): () 1x1+0+0 +0+0
65011712 (has no name): () 1x1+0+0 +0+0
62914562 "georg@barry:": ("Alacritty" "Alacritty") 941x1026+10+40 +10+40
52428802 "georg@barry:": ("Alacritty" "Alacritty") 941x506+965+40 +965+40
27262978 "georg@barry:~": ("Alacritty" "Alacritty") 941x506+965+560 +965+560
60817408 (has no name): () 1x1+0+0 +0+0
58720256 (has no name): () 1x1+0+0 +0+0
56623104 (has no name): () 1x1+0+0 +0+0
54525952 (has no name): () 1x1+0+0 +0+0
35651584 (has no name): () 1x1+0+0 +0+0
33554432 (has no name): () 1x1+0+0 +0+0
31457280 (has no name): () 1x1+0+0 +0+0
29360128 (has no name): () 1x1+0+0 +0+0
8388611 (has no name): () 1x1+-1+-1 +-1+-1
16777224 (has no name): () 1x1+-1+-1 +-1+-1
20971528 (has no name): () 1x1+-1+-1 +-1+-1
18874376 (has no name): () 1x1+-1+-1 +-1+-1
25165829 "Polybar tray window": ("tray" "Polybar") 80x30+1840+0 +1840+0
3 children:
18874379 "pamac-tray": ("pamac-tray" "Pamac-tray") 16x16+8+7 +1848+7
1 child:
18874380 (has no name): () 1x1+-1+-1 +1847+6
16777227 "NetworkManager Applet": ("nm-applet" "Nm-applet") 16x16+32+7 +1872+7
1 child:
16777228 (has no name): () 1x1+-1+-1 +1871+6
20971531 "blueberry-tray.py": ("blueberry-tray.py" "Blueberry-tray.py") 16x16+56+7 +1896+7
1 child:
20971532 (has no name): () 1x1+-1+-1 +1895+6
25165825 "polybar-mainbar0_eDP-1-1": ("polybar" "Polybar") 1920x30+0+0 +0+0
20971521 "blueberry-tray.py": ("blueberry-tray.py" "") 10x10+10+10 +10+10
8388609 "xfce4-notifyd": ("xfce4-notifyd" "Xfce4-notifyd") 10x10+10+10 +10+10
18874369 "pamac-tray": ("pamac-tray" "Pamac-tray") 10x10+10+10 +10+10
16777217 "NetworkManager Applet": ("nm-applet" "Nm-applet") 10x10+10+10 +10+10
14680065 "xfce4-power-manager": ("xfce4-power-manager" "Xfce4-power-manager") 10x10+10+10 +10+10
12582913 "polkit-gnome-authentication-agent-1": ("polkit-gnome-authentication-agent-1" "Polkit-gnome-authentication-agent-1") 10x10+10+10 +10+10
10485764 "picom": ("picom" "picom") 1x1+0+0 +0+0
4194305 "LG3D": () 1x1+-100+-100 +-100+-100

t-rec -l

Output:

Window | Id
 (10x10) | 4196652
 (10x10) | 4196657
 (10x10) | 4196662

[sassman]

Good to know, that sounds a bit like a different issue (and the missing window names I can already reproduce).

[sassman]

The more I read about xmonad and it's configurability the more I wonder if you could share your xmonad config file if you have any?

Like https://hackage.haskell.org/package/xmonad-contrib-0.16/docs/XMonad-Config-Prime.html

[carrascomj]

Sure, I don't have it public on Github but here it is https://pastebin.com/3fGqJ5QM . It is a bit messy, I rely on autostart scripts for tray, compositor, etc. and I use it with polybar so I have to hack around with xmonad-log to do what I want.

I'd rater look at this one, which is better documented and shows the configurability part much better than mine.

[sassman]

As I'm not familiar with xmonad at all, I can only guess right now, but maybe the import XMonad.Layout.ResizableTile has something to do with this behaviour.

I was not yet able to reproduce it, but found a different interesting behaviour on xmonad #30 that needed config adjustments in xmonads default config file. (only partially related)

[carrascomj]

But I tried it on another (more obscure but rusty) tiling window manager - leftwm - an the behavior is the same. I could not mess with anything there because it is not as configurable as xmonad.

I would be happy with a xmonad-specific solution that I change it in the config and it works but it would be nice if others could verify this in other tiling WMs, since maybe xmonad is too niche (well, tiling is maybe too niche in the first place, but that's up to you hehe).

[sassman]

Alright I will check this WM out as well. Meanwhile (since on Linux Mint and xmonad it is working) I wonder if you could also supply the output of inxi -SGxx to figure out the more differences between Arch Linux and Mint

[carrascomj]

There you go

inxi -SGxx

Output:

System:
  Host: barry Kernel: 5.9.14-arch1-1 x86_64 bits: 64
  compiler: gcc v: 10.2.0 Desktop: N/A wm: LG3D dm: LightDM
  Distro: ArcoLinux
Graphics:
  Device-1: Intel UHD Graphics 630 vendor: Lenovo driver: i915
  v: kernel bus ID: 00:02.0 chip ID: 8086:3e9b
  Device-2: NVIDIA GP107M [GeForce GTX 1050 Mobile]
  vendor: Lenovo driver: nvidia v: 455.45.01 bus ID: 01:00.0
  chip ID: 10de:1c8d
  Device-3: Syntek EasyCamera type: USB driver: uvcvideo
  bus ID: 1-8:3 chip ID: 174f:241a
  Display: x11 server: X.Org 1.20.10 compositor: picom
  driver: modesetting,nvidia resolution: 1920x1080~60Hz
  s-dpi: 96
  OpenGL: renderer: GeForce GTX 1050/PCIe/SSE2
  v: 4.6.0 NVIDIA 455.45.01 direct render: Yes

I still need to try what you proposed in the other issue.

[sassman]

Good news, was able to reproduce it and have also an explanation why this is happening. So the bugfix is not too far away. I have reproduced the issue on ArcoLinux on this WM setup:

System:
  Host: bottle Kernel: 5.4.86-1-lts x86_64 bits: 64 compiler: gcc v: 10.2.0 
  Desktop: Xfce 4.16.0 tk: Gtk 3.24.24 wm: xfwm4 dm: LightDM 
  Distro: ArcoLinux 

However, the issue is not so much related to the WM, but more precisely related to the fact that the terminal used, has transparency support, so the screenshot that gets captured has transparency too. Why is transparency a problem you might ask, glad you've asked. On Ubuntu there was a transparent glow around the borders of the window, caused by a compositor effect (like a drop shadow effect) in order to get rid of this, there is a smart feature that shrinks the image to a size where the dimensions don't have transparency.

[sassman]

@carrascomj could you please double-check the branch fix/xmonad-issue-26 and see if that also solved the problem in your case?

I tested multiple terminal on multiple distros all with some and none opacity and all cases behave now good.

[carrascomj]

@sassman It works! So the problem was something with having a composer, right? (I mean, my terminal is not transparent but I have picom running in the background).

[sassman]

Not sure if that was the root cause. But the convert -trim call have somehow caused it, I assume that there was some sort of opacity maybe just a tiny bit. That caused -trim to behave the way it did, meaning not correctly differentiating between the outer background and the inner background of the terminal.

However, the PR needs a bit more fine-tuning to solve some causes that misbehaves on MacOS then it would be ready. So you can expect a release pretty soon.

[sassman]

@carrascomj happy to announce that the final bugfix is out (v0.4.2 it is).

Thanks again for your amazing and responsive help, without folks like you such quick fixes would not be possible.

[carrascomj]

Awesome, thank you for this software!