Weird window decoration flickering with picom v8+

[arvl130]

Platform

Arch Linux
Linux 5.6.11-arch1-1
Mesa 20.0.6-2

GPU, drivers, and screen setup

ThinkPad X220 (Intel HD 3000)
Xorg 1.20.8-2 (with the modesetting driver)

Environment

I run bspwm as a window manager with the modesetting driver for X. The WM only renders rectangles around windows as a decoration, but even that is somehow flickering.

picom version

Latest git:

➜ picom --diagnostics
**Version:** vgit-0b377

### Extensions:

* Shape: Yes
* XRandR: Yes
* Present: Present

### Misc:

* Use Overlay: Yes* Config file used: /home/arvl/.config/picom.conf

### Drivers (inaccurate):

modesetting

Though it also happens with the latest release (v8):

➜ picom --diagnostics
**Version:** vgit-e553e

### Extensions:

* Shape: Yes
* XRandR: Yes
* Present: Present

### Misc:

* Use Overlay: Yes* Config file used: /home/arvl/.config/picom.conf

### Drivers (inaccurate):

modesetting

Configuration:

I have a rather simple one:

backend = "glx";
vsync = true;

# Shadows
shadow = true;
shadow-radius = 4;
shadow-offset-x = -4;
shadow-offset-y = -4;
shadow-opacity = 0.4;
shadow-exclude = [
    "! name ~= ''",
    "class_g = 'firefox' && argb",
    "class_g = 'Tor Browser' && argb",
    "_GTK_FRAME_EXTENTS@:c",
    "_NET_WM_STATE@:32a *= '_NET_WM_STATE_HIDDEN'"
];

wintypes:
{
    dnd = {
        shadow = false;
    }
}

Steps of reproduction

1. Install the latest picom release from the Arch Linux official repos. Or, the latest git using this Arch Linux AUR package.
2. Run picom in the background (-b), or foreground as normal.
3. Wait for sometime.
4. Get this kind of flickering.

Expected behavior

No flickering, like with release v7.5.

Current Behavior

Flickering after some time. I should note that even when I pass --show-all-xerrors, and run it in the terminal in foreground. No errors seem to show up at all. It just kinda flickers like shown in the video.
It doesn't seem to happen when using the xrender backend (instead of glx). But then, I get mild tearing using that.

Stack trace

It does not crash. So not sure what to do here.

Other details

• I have no clue what triggers this, unfortunately. So my information here seems to be rather lacking. If there are any ways I could help track this issue. Please tell me.
• Here are more videos on the window decoration flickering: #1 #2 #3, if that helps.

[ghost]

I see the same thing. I'm also using bspwm but with Nvidia. I did not have the flickering on my borders with version 7.5.

[absolutelynothelix]

if there is no issue with picom v7.5 would be good to do git bisect to see what commit introduced this issue. btw, i guess it's related to #375.

[arvl130]

I've been testing use-damage = false for a few hours now (like recommended in #375) and I think I can safely atest that this option does fix my issue.

I should add though, that the issue doesn't seem to pop up when using xf86-video-intel. It only shows when using the Xorg modesetting driver based on my testing.

I'm a bit worried too with the note in the help message. Saying using the option might degrade performance. So preferably, it would be nice if we didn't have to use it. It's your call as the devs tho ( :

[krummja]

Just wanted to chime in that I was having a similar issue with GUI elements blinking and terminal lag on Regolith Desktop, and the suggestion to set use-damage = false fixed the issue.

[osimplex]

I see something like this, but on spesctrwm, Arch Linux. I did not have the flickering on my borders with version 7.5, I'm now using the old picom-7.5-3 from Arch repos, because this.

[arvl130]

@mighty9245 Not much to add here, but I can confirm 93f0d80 does introduce this issue for me.

Testing commits back up to tag v7 (with use-damage = true), it looks like this was already an issue even before the option was made default. It's likely we're hitting the same bug as #237.

I will have to test if the issue persists with the experimental backends and with branch next, as everything was done with the old backends.

Edit: Still the same for fd6ff82. Flickers with both old and new backends.

[osimplex]

Using latest version of picom on Arch Linux (today v8-3), with use-damage = false, all works as expected. man says no-use-damage, but this parameter doesn't work in config file, heve to use the parameter from previous version that still works.

#237 has a talk about a problem maybe related. But #375 have a discussion too, where I caught the use-damage = false tip.

[jlucier]

use-damage = false seems to stop the flickering as many have stated, however the performance hit @arvl130 mentioned is pretty rough... It seems to differ between applications. For instance, my browser seems to render very quickly without noticeable lag, but even running ls in my terminal can take a pretty painful amount of time to show results.

I didn't have any issues until I switched my graphics driver from the XOrg driver to Nvidia 450 (which I assume changes the glx implementation that will be used?). I too am running Regolith Desktop. @krummja or anyone else: any suggestions?

---

EDIT:
I found this regolith issue, which suggests using --xrender-sync-fence option, and that seems to both fix the issue and maintain draw performance 😃

EDIT 2:
While the stuff I mentioned above does work, I will say that the solution is a bit intolerant to hibernate/suspend. After bringing the computer back awake certain segments of windows do not get redrawn.

[yshui]

@arvl130 looks like your window have a border in the recording, is it really there, or just an artifact from picom?

Can you use apitrace to get a trace of picom? That might be helpful.

[mortezadadgar]

@arvl130 looks like your window have a border in the recording, is it really there, or just an artifact from picom?

Can you use apitrace to get a trace of picom? That might be helpful.

I have faced very similar issue with dwm and modesetting driver as soon as I got border flickering killed picom and catched the log, the border window flickering occurred with firefox
picom.log

[mortezadadgar]

@yshui would you take a look at log

[dm17]

Switching to xcompmgr fixed this mysterious issue for me - no picom-based solutions seemed to work.