damage tracking is racy, losing some (mainly border) updates

[liskin]

Platform

Debian testing amd64

GPU, drivers, and screen setup

ThinkPad T25 (T470 equivalent), i.e. Kaby Lake, Intel HD 620, no external screen, just eDP display

package versions

``` xserver-xorg-core 2:1.20.4-1 (modesetting driver, not intel, so that's in the core) libgl1-mesa-dri:amd64 19.1.6-1 ```

glxinfo -B

``` name of display: :0 display: :0 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel Open Source Technology Center (0x8086) Device: Mesa DRI Intel(R) HD Graphics 620 (Kaby Lake GT2) (0x5916) Version: 19.1.6 Accelerated: yes Video memory: 3058MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 620 (Kaby Lake GT2) OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.1.6 OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL version string: 3.0 Mesa 19.1.6 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.1.6 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 ```

Environment

xmonad (configuration here: https://github.com/liskin/dotfiles/tree/home/.xmonad), for easier reproduction I killed xmobar, trayer and compton and launched compton from the command line using --config /dev/null

Compton version

I can reproduce this using both v7.3 (my updated Debian package, sources here: https://gitlab.com/liskin/compton) and current next (de5d5ca9bb3aa4a6c47d4ff180377eb02440dae6, actually https://github.com/yshui/compton/pull/236 but that's not going to make any difference).

compton --diagnostics

``` **Version:** vgit-54358 ### Extensions: * Shape: Yes * XRandR: Yes * Present: Present ### Misc: * Use Overlay: Yes * Config file used: /home/tomi/.config/compton.conf ### Drivers (inaccurate): modesetting ```

Steps of reproduction

Scenario 1, no --vsync, damage update missed entirely:

1. use a tiling window manager like xmonad configured to use borders to indicate focused window
2. compton --config /dev/null --backend glx --use-damage
3. open a bunch of windows in quick succession
4. if you're (un)lucky (doesn't happen every time, unfortunately), the last window opened will have black border instead of whatever focused color it should have

video: compton-no-vsync.zip

Scenario 2, --vsync, damage update ignored when drawing into aged buffers:

1. tiling wm like above
2. compton --config /dev/null --backend glx --use-damage --vsync
3. open a bunch of windows in quick succession
4. if you're (un)lucky, typing into the last window (any screen update that causes a buffer flip, actually) will cause flickering of its border (in very rare cases, another window's border is flickering, and I've seen a whole window's contents flicker, too, once or twice)

video: compton-vsync.zip

[liskin]

Just fyi, I can reproduce this at commit 5d654e687788253aa9f9c5b9fb528a98bb085c2d with ./compton --config /dev/null --backend glx --glx-swap-method buffer-age and even with --glx-copy-from-front. So either my X server isn't reporting the damage, or this problem has been there almost forever.

[yshui]

@liskin hmm, if this is really an issue a lot of people would've reported this by now...

can you attach an apitrace, maybe that would give us more information.

[aufkrawall]

@liskin Could you test with experimental xrender backend + vsync? Afair the buffer-age code is shared among backends since yshui refactored it, but who knows.

[liskin]

@yshui Yeah, it is weird, but I'm a magnet for weird bugs so I still believe the issue is somewhere out there, other people are just way luckier than me. I'll try to obtain the apitrace later today/this week.

@aufkrawall Oh, I did test the new backends as well, apparently I forgot to mention it here. And as I mentioned, I can reproduce without vsync, therefore without the buffer-age code being used at all.

[aufkrawall]

buffer-age also works without vsync: Without both, Compton renders as fast as possible and thus fully utilizes the GPU. This is not the case with just buffer-age, even without vsync.

Apparently new --no-use-damage command must be used at run time, not in the config. At least I got tricked by it. ;)

[liskin]

But without --vsync, there's no need for multiple buffers at all, is there?

[yshui]

But without --vsync, there's no need for multiple buffers at all, is there?

OpenGL still get its front/back buffers even if you disable vsync

[bsdice]

@yshui Yeah, it is weird, but I'm a magnet for weird bugs so I still believe the issue is somewhere out there, other people are just way luckier than me. I'll try to obtain the apitrace later today/this week.

Add me to the list of affected users. Running Arch+i3+compton on an Intel Pentium Silver N5000 with Intel UHD 605 GPU. The panel is running at 60 fps. I am on kernel 5.3.1 that has "automatic framebuffer compression" (fbc) already disabled by default, to eliminate the top of the screen artifacts.

The effects are as described, I open a console that has only slim blue default i3 borders and then I just run "top". On some refreshes by top, the blue borders blink in and out of existence. No idea which parallel universe they go to. ;-) Same when there is other action, like compiling a package. After bisecting my config, I found that use-damage is the culprit. I want to continue using compton to eliminate that aweful tearing in video playback.

Current working config:

backend = "glx"; glx-no-stencil = true; glx-no-rebind-pixmap = true; vsync = true; use-ewmh-active-win = true;