I3-gaps window errors

#1

I just wanted to ask if anybody else experiences this - since a couple of days (updating daily but not sure which update caused it because I did not notice it right away) my windows are sometimes not displaying correctly using i3-gaps as in when I switch workspaces, an “image” of the previous workspace is still displayed instead of the empty/busy new workspace. Also, tiled windows are sometimes only showing a border and no content within and I can not close them with my keybinds but have to kill them via console. Until killing them they are still running in the background, though. This is not app-specific, meaning it affects terminal, browser, etc.
I will post a screenshot when I see it again as I am not yet sure how I can reliably reproduce this error.

So is anybody else experiencing this? Can anybody point me in the right direction here? I searched online but was not able to find a bugreport or issue similar to this, yet.

Thanks, cheers

1 Like

#2

Haven’t noticed anything like this, running i3-gaps on 3 machines (2 x Arch + Void Linux).

0 Likes

#3

Thanks for your reply, are you using a multihead setup as well?

0 Likes

#4

Yes, a secondary display attached to the laptop by HDMI.

0 Likes

#5

Hmm, interesting - thanks for the information. I will try and scrot the issue when it appears again.

0 Likes

#6

The i3-gaps package was last updated on 2019-01-29. I’d focus on possible graphics-related issues if I were you.

0 Likes

#7

Here is a scrot of a pretty good example: I had my screen locked and after unlocking, the lockscreen persisted on one screen while the other screen was fully functional. The lock screen was “frozen” on two workspaces at first but after switching back and forth several times and closing some other windows, all of a sudden it disappeared and the second screen worked again. However, another window I had opened did then not display properly anymore.

Graphics drivers were not updated for some time, I am guessing more towards a software conflict of another kind that leads to window-update errors somehow… maybe something like Compton interferes? Unfortunately I do not even know how to debug something like this…

0 Likes

#8

This could be easily checked, by turning off Compton in the i3 config file.

0 Likes

#9

Indeed, it certainly could. But as the involvement of compton was a more or less random guess by me, a thousand other things could be responsible.
So really, it comes down to the fact that I would like to have an idea of what I am dealing with before trying random fixes.

0 Likes

#10

If you use Compton, it should be the first suspect. There were several subsequent updates to it lately.

0 Likes

#11

Alright then. Well it seems compton is loading with i3 as I can killall compton and my transparency in termite disappears, however - and this is kind of embarrassing - I can not find where compton is called to start with i3. There is nothing in the i3 config file, nothing in the .xinitrc,… Any hint on where I can permanently disable compton?

0 Likes

#12

Well, I have no machine running AL here. In my current config it’s just:

exec_always --no-startup-id compton

AL does it in another way. Wasn’t it somewhere in the al-compositor script?

exec --no-startup-id al-compositor --start

If not, I’ll check at home.

0 Likes

#13

It was indeed the al-compositor part, thanks! Will try and see if I can reproduce anymore.

edit: on the compton github page (https://github.com/yshui/compton/releases) it says that since v.6 (11 days ago) vsync is now a boolean number and before used to be “none” or similar… so I think everyone with compton and vsync enabled should experience some issues? Would this be a reason to maybe update the archlabs-script package?
This might be what caused my issues as well, but I will have to do further testing to confirm.

0 Likes

#14

It may depend on the compton configuration. Did you change anything? I used to use the compton-conf package and the configuration was auto-generated. After the first of the recent series of updates, compton started crashing on reading this. I deleted the config file (together with compton-conf itself) and stopped thinking about it. :smiley:

0 Likes

#15

I never changed anything in the compton config manually until today.
For now, though, I went with disabling compton completely and since then was not able to reproduce the error. Tomorrow I will go on and try to re-enable compton with disabled vsync and glx and see what happens.

1 Like

#16

Unfortunately, yesterday the error re-appreared with compton still disabled (although only after a long-day’s work).
I have now reenabled compton with vsync=false; and will see what happens today. Will keep you up-to-date.

0 Likes

#17

It seems I’ll be playing with compton, too. For several days I’ve been unable to record the screen w/o artifacts like tearing or blinking Tint2 panel. It used to work flawlessly for years.

0 Likes

#18

Disabling compton helped: no more trash in the video:

1 Like

#19

Interesting. Can you try enabling compton and setting vsync=false; in your compton.conf and try recording again to see what happens? I enabled compton yesterday with vsync=false and so far no errors.

0 Likes

#20

Alright, I took 2 videos 45 seconds long. The same display, same applications running.

vsync = true; - tearing starts at about 0:25:

vsync = false; - no tearing occurred:

1 Like