Glitchy texture behind windows

[sambazley]

Output of i3 --moreversion 2>&- || i3 --version:

Binary i3 version:  4.14.1 (2017-09-24) © 2009 Michael Stapelberg and contributors
Running i3 version: 4.14.1 (2017-09-24) (pid 30561)bort…)
Loaded i3 config: /home/user/.config/i3/config (Last modified: Sun 14 Jan 2018 20:27:59 GMT, 4766 seconds ago)

The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3

What I did:

Opened two windows in tabbed mode (mod+w), focused the parent container (mod+a), opened a new window, then set the parent container to split mode (mod+e).

What I saw:

https://i.imgur.com/K5NR8mu.png
A texture is visible between the windows and the wallpaper. The texture stretches across my primary monitor, and is initially only a few pixels tall (about 25). If I mouse down inside a window or change focus to another window, the height of the texture increases. If I mouse down or mouse up on the wallpaper, the height of the texture will increase for both events. Every time the height increases, the contents of the texture change. The height of the texture will only increase up until it reaches the y coordinate of 680. After it reaches this height, it's contents do not change when I change focus or mouse up/down.

The height of the texture resets to it's initial height if I change the parent container to tabbed mode, and back to split mode. (ie toggle gaps).

xprop reports that the texture has a class name of "i3-frame", where as much more information is reported if I click below the texture.

[user@SamLinux ~]λ xprop                                                         :)
WM_CLASS(STRING) = "i3-frame", "i3-frame"
[user@SamLinux ~]λ xprop                                                         :)
AT_SPI_BUS(STRING) = "unix:abstract=/tmp/dbus-B65tH2BEE7,guid=f5aaa429a480512714ccd72e5a5bbc8d"
I3_SHMLOG_PATH(UTF8_STRING) = 
I3_CONFIG_PATH(UTF8_STRING) = "/home/user/.config/i3/config"
I3_PID(CARDINAL) = 30561
I3_SOCKET_PATH(UTF8_STRING) = "/run/user/1000/i3/ipc-socket.30561"
_NET_ACTIVE_WINDOW(WINDOW): window id # 0x2000003
_NET_CLIENT_LIST(WINDOW): window id # 0x140003b, 0xe00010, 0x2000003, 0x3600010, 0x3c00029, 0x1e00003
_NET_CLIENT_LIST_STACKING(WINDOW): window id # 0x140003b, 0xe00010, 0x3c00029, 0x3600010, 0x1e00003, 0x2000003
_NET_CURRENT_DESKTOP(CARDINAL) = 2
_NET_DESKTOP_VIEWPORT(CARDINAL) = 1920, 0, 1920, 0, 1920, 0, 0, 0
_NET_DESKTOP_NAMES(UTF8_STRING) = "2: ", "3: ", "4: ", "1"
_NET_NUMBER_OF_DESKTOPS(CARDINAL) = 4
_NET_SUPPORTED(ATOM) = _NET_SUPPORTED, _NET_SUPPORTING_WM_CHECK, _NET_WM_NAME, _NET_WM_VISIBLE_NAME, _NET_WM_MOVERESIZE, _NET_WM_STATE_STICKY, _NET_WM_STATE_FULLSCREEN, _NET_WM_STATE_DEMANDS_ATTENTION, _NET_WM_STATE_MODAL, _NET_WM_STATE_HIDDEN, _NET_WM_STATE, _NET_WM_WINDOW_TYPE, _NET_WM_WINDOW_TYPE_NORMAL, _NET_WM_WINDOW_TYPE_DOCK, _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_UTILITY, _NET_WM_WINDOW_TYPE_TOOLBAR, _NET_WM_WINDOW_TYPE_SPLASH, _NET_WM_WINDOW_TYPE_MENU, _NET_WM_WINDOW_TYPE_DROPDOWN_MENU, _NET_WM_WINDOW_TYPE_POPUP_MENU, _NET_WM_WINDOW_TYPE_TOOLTIP, _NET_WM_WINDOW_TYPE_NOTIFICATION, _NET_WM_DESKTOP, _NET_WM_STRUT_PARTIAL, _NET_CLIENT_LIST, _NET_CLIENT_LIST_STACKING, _NET_CURRENT_DESKTOP, _NET_NUMBER_OF_DESKTOPS, _NET_DESKTOP_NAMES, _NET_DESKTOP_VIEWPORT, _NET_ACTIVE_WINDOW, _NET_CLOSE_WINDOW, _NET_MOVERESIZE_WINDOW
_NET_WM_NAME(UTF8_STRING) = "i3"
_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x400035
RESOURCE_MANAGER(STRING) = "Xcursor.theme:\tpixelfun3\nrofi.color-active:\t#26404B, #ffffff, #26404B, #26404B, #ffffff\nrofi.color-enabled:\ttrue\nrofi.color-normal:\t#2E3A40, #ffffff, #29353B, #354D58, #ffffff\nrofi.color-urgent:\t#632627, #ffffff, #632627, #632627, #ffffff\nrofi.color-window:\t#2E3A40, #2E3A40, #13191C\nrofi.scroll-method:\t1\nrofi.ssh-command:\t{terminal} -e \"{ssh-client} {host}\"\n"
XIM_SERVERS(ATOM) = @server=ibus
ESETROOT_PMAP_ID(PIXMAP): pixmap id # 0x600001
_XROOTPMAP_ID(PIXMAP): pixmap id # 0x600001
GDK_VISUALS(INTEGER) = 820, 1238
XFree86_DDC_EDID1_RAWDATA(INTEGER) = 0, -1, -1, -1, -1, -1, -1, 0, 16, -84, 2, -16, 76, 75, 65, 50, 5, 17, 1, 3, 104, 38, 31, 120, -18, -54, -10, -93, 87, 71, -98, 35, 17, 79, 84, -91, 75, 113, 79, -127, -128, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 48, 42, 0, -104, 81, 0, 42, 64, 48, 112, 19, 0, 124, 49, 17, 0, 0, 30, 0, 0, 0, -3, 0, 56, 76, 30, 81, 14, 0, 10, 32, 32, 32, 32, 32, 32, 0, 0, 0, -1, 0, 80, 82, 48, 57, 57, 55, 49, 84, 50, 65, 75, 76, 10, 0, 0, 0, -4, 0, 68, 69, 76, 76, 32, 83, 69, 49, 57, 55, 70, 80, 10, 0, -64
_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "gb,us", ",dvorak", ""
XFree86_has_VT(INTEGER) = 1
XFree86_VT(INTEGER) = 7
Xorg_Seat(STRING) = "seat0"

https://i.imgur.com/zMPxTvG.jpg The white in this screenshot is transparent (ie I can see my wallpaper here)
https://i.imgur.com/xOEZGRW.jpg
https://i.imgur.com/VezAsl3.jpg

I am using the open source AMDGPU driver.

My config (I have disabled compton for testing)

I've tested it in a virtual machine, using near enough the same config, where is works as I would expect. https://i.imgur.com/B9hSoH5.jpg

[Airblader]

First of all thanks for the quite details report, that's great! Unfortunately, this comes from a limitation of how i3 draws decorations and is a »known issue«. Preventing this involves a complicated refactoring within i3 which, apart from having to be done in the first place, I wouldn't want to merge in i3-gaps because it makes it impossible to stay up to date with upstream.

The good news is that the change would also be accepted in i3, but the bad news is that it is far from trivial and I personally won't be working on it in the foreseeable future. The corresponding ticket is i3/i3#1966. A detailed comment specifically can be found here: i3/i3#1966 (comment). As explained there, I did already work on a pretty involved switch to cairo which improved the situation significantly compared to before, but it's just not quite enough.

If someone wants to fix this in i3 (and by extension in i3-gaps), that's great, but I'm going to close this here as I am not willing to fix this without going through i3 itself where we have the aforementioned ticket already.

[sambazley]

Why would the way that i3 draws decoration be affected by key events?

If everything looks normal below i3-frame, why is it necessary at all?

Why does it only happen on my host OS, and not in the virtual machine? Is it something to do with AMDGPU? Similar effects can be seen when opening windows (especially games) that haven't finished initializing.

[Airblader]

Why would the way that i3 draws decoration be affected by key events?

What you're essentially seeing is memory garbage. It can be affected by whatever.

If everything looks normal below i3-frame, why is it necessary at all?

A lot of that window is »undrawn« area, but we do use it to draw the decorations. That's why, by the way, for i3-gaps you need to disable titlebars. Your situation has just the unfortunate side effect that titlebars are drawn even if borders are disabled, which is why the problem resurfaces here.

Is it something to do with AMDGPU?

Whether and when the problem appears probably depends on a lot of things such as video driver and compositor, yeah. Playing with compositor settings might make it better, but at the end of the day this is a bug (or at least a design problem) in i3 which isn't so easy to fix. I know it's not very satisfying, but it is what it is.

BTW, how did you disable compton for these screenshots and still have transparency? There is no transparency without a compositor.

[sambazley]

What you're essentially seeing is memory garbage. It can be affected by whatever.

What makes you say that? Wouldn't that result in this behaviour being very random unpredictable? This is not the case. I can trigger the height changes consistently.

A lot of that window is »undrawn« area, but we do use it to draw the decorations.

Why does xprop return different information for this area?

That's why, by the way, for i3-gaps you need to disable titlebars.

If I enable titlebars, I get a similar effect https://i.imgur.com/yP14seO.jpg. However, these bars do not contain random data, and do not respond to key and mouse events. If I start compton, these bars disappear, where as the glitchy bars do not.

how did you disable compton for these screenshots

pkill compton. I've checked that it's not running with ps.

and still have transparency?

What transparency? You mean from the second screenshot? I may have had compton running there, but I have tested this without it.

[Airblader]

What makes you say that?

I frankly don't care much about what specifically causes the garbage memory effects to change, predictably or not. I'm not arguing that there is no bug here; there absolutely is.

I've spent countless hours working on changes ultimately intended to fix this (i3/i3#2065, i3/i3#1933, …). Granted, maybe I'm just missing the holy grail of easily fixing all of this, but until someone can convince me otherwise with something substantial I'm going to continue believing that this requires (further) major changes in i3. :-)

Why does xprop return different information for this area?

The two xprop results you gave are from a frame window and the X root window, respectively. Which one you get somewhat depends on where exactly you click (you have to know how i3 draws decorations).

If I start compton, these bars disappear, where as the glitchy bars do not.

Maybe for the moment; it will come back, though. This is even documented in compton's wiki.

However, these bars do not contain random data

Black is also random. :-) Black, pink, cats or garbage – it doesn't make a difference. It's not supposed to be there, we know that.

[sambazley]

I frankly don't care much about what specifically causes the garbage memory effects to change, predictably or not.

It's not the "garbage memory effects" that are predictable. It's the way the height of the garbage changes with events. If that was caused by garbage, it wouldn't be consistent and predictable.

I'm not arguing that there is no bug here

I'm not saying that you think there isn't. I'm saying that there are multiple bugs involved.

The two xprop results you gave are from a frame window and the X root window, respectively. Which one you get somewhat depends on where exactly you click

I could click on the same pixel twice, and get different results before and after the height changes. It's not just rendering my wallpaper through the texture - it's rendering below it.

Black is also random

Sure, black can be random. I've closed and reopened these windows many times, and they are consistently black. The odds of each pixel being black each time is extremely low. It's not random. Maybe they'll change color later. If they do, that's different behaviour.

This shows how the window size is changing, not just the data. Perhaps the geometry and corner data could be useful.
https://www.youtube.com/watch?v=c7DL2ou5c78

EDIT: I've just realised that the height of i3-frame increases by my gaps inner value on each event.

[Airblader]

I'm saying that there are multiple bugs involved.

Well, fair enough. I'll reopen for now on the assumption that that's correct. However, I won't have time to look into this myself at the moment.

[lromor]

Hi, I'm having the very same issue. No compositors involved. Just pure i3 gaps, with 3+ containers and some gaps. If you start switching between default and tabbed you start collecting on top these glitches.

Could it be because in the tabbed layout you cannot disable the windows titles?

[Airblader]

FYI, i3/i3#3481 and/or i3/i3#3479 might improve this situation (both open tickets at this time).

[rudolfschmidt]

Same problem, only a restart of i3 helps

[Hippo0o]

I come across this bug quite often. Is it still getting worked on?
https://www.youtube.com/watch?v=iPfiy0D-LP4

[Airblader]

The state of each involved issue (this and the referenced ones) can be seen in the issues. The answer is: no, there has not been any recent work.

[Airblader]

I'm thinking that i3/i3#4280 could likely fix this. If someone wants to try it out please go ahead and let us know here.

[stephan-t]

I tried i3/i3#4280 in the latest i3-gaps version 4.19.1 and it did not fix this issue. It actually broke border colours, making it consistently black.

i3-bug.mp4

[Airblader]

That PR ended up having some issues and got reverted. It's now merged as i3/i3#4336, which means the current gaps-next branch has this included. If the issue persists the hypothesis that it might be fixed by it was incorrect. :-)

[stephan-t]

I should have looked more closely at that PR to see the revert. The merge from i3/i3#4336 does prevent the border issue but, unfortunately, this graphical glitch issue still persists.

[641i130]

I get this too.

[Airblader]

I'm closing this issue has i3-gaps is being migrated into i3. Please verify on the latest next branch there as it has seen some fixes already. If this issue still applies, please reopen it in i3.