Picom: Worse screen tearing with recent versions

[Avi-D-coder]

Platform

Arch Linux 4.19.10-arch1-1-ARCH
Compton built from git.

GPU, drivers, and screen setup

Intel Corporation HD Graphics 620 (rev 02)

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: 18.3.1
    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 18.3.1
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 18.3.1
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.3.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Environment

i3

Compton setup

**Version:** v4-rc1-32-g90e1974

### Extensions:

* Name Pixmap: Yes
* Shape: Yes
* XRandR: Yes
* Present: Present

### Misc:

* Use Overlay: Yes
* Config file used: None

Compton configuration:

compton -CG --config /dev/null --backend glx

Steps of reproduction

1. Built from latest commit on next branch at Wed 05 Dec 2018 04:42:36 PM EST small amount of tearing in random locations in chrome when scrolling GitHub and others sites.
2. Packages built from latest commit on next branch at Sun 16 Dec 2018 08:40:47 PM EST and present Fri 21 Dec 2018 01:10:08 AM EST major tearing line 3/4 up screen in chrome when scrolling GitHub and others sites. The tearing is worse than without compton running.

I am not sure what commit caused the issue, I will try to bisect tomorrow.

[dikiaap]

There are some changes at #66 and I have screen tearing when using glx backend with the vsync flag is "none"

Try by adding --vsync vsync-method to the command has fixed my issue

List of V-sync method according to the man page:

• none: No VSync
• drm: VSync with 'DRM_IOCTL_WAIT_VBLANK'. May only work on some (DRI-based) drivers.
• opengl: Try to VSync with 'SGI_video_sync' OpenGL extension. Only work on some drivers.
• opengl-oml: Try to VSync with 'OML_sync_control' OpenGL extension. Only work on some drivers.
• opengl-swc: Try to VSync with 'MESA_swap_control' or 'SGI_swap_control' (in order of preference) OpenGL extension. Works only with GLX backend. Known to be most effective on many drivers. Does not guarantee to control paint timing.
• opengl-mswc: Deprecated, use 'opengl-swc' instead.

[yshui]

@dikiaap @Avi-D-coder Yep. compton has started explicitly disabling vsync when vsync is set to none. Previously vsync might be enabled by default by your video drivers, and is causing people who don't want vsync some unwanted lag.

[Avi-D-coder]

So I did some experimenting.

The two least tearing configs with either xf86-video-intel or themodesetting` driver are:

1. ##### opengl-swc:
   compton -CG --config /dev/null --backend glx --vsync opengl-swc --glx-swap-method -1 --glx-no-stencil --sw-opti

1. ##### opengl drm:
   compton -CG --config /dev/null --backend glx --vsync drm --glx-swap-method -1

With xf86-video-intel opengl-swc and drm produces many very small tears when scrolling.
With modesetting neither produce decent results. opengl-swc produces many small tears.

What is strange is that drm + opengl + modesetting produces the clearest easiest to read output when scrolling and the best gpu/cpu performance. The problem is there it also produces a very clear diagonal tear line descending from the top right.

[yshui]

@Avi-D-coder Can you explain what you meant by "many small tears"? That sounds like some kind of visual artifact to me. If you have screenshots/recordings, that will be great.

[Avi-D-coder]

With the modesetting driver and drm: https://youtu.be/jM9KHHYsNT8

The tearing did not record very well. I don't think it is even visible.
The other configs produce similar tearing, but more evenly spread-out around the screen.

By small tears I mean small horizontal line segments that slightly distort the image such that content is non contiguous. The line segments are randomly placed around the screen. They are more apparent when utilizing the GPU (ex. playing video) and scrolling in a different window.

[yshui]

@Avi-D-coder So it is not a horizontal line that goes across the entire screen?

Can you try not setting glx-swap-method?

[Avi-D-coder]

• modesetting + drm = tear line across whole chrome window at least partially at a diagonal.
• Without compton = horizontal tear line across whole chrome window.

• With any other driver config combination varying amount of small tears not across the whole window usually.
  These tear lines don't stay in the same area like the bigger tears, but do make it hard to read text if I am scrolling. It almost looks like flickering, but not quite.

  As long as the text is not under a big tear line I normally can read it while scrolling with modesetting + drm or no compton.

[yshui]

Can you try doing a bisect?

[jrudess]

I'm also seeing new tearing issues with Nvidia. My test case is amazon video in chromium (not full screen). Bisect led to e2182bb00bb418d616dc047d1f2c280e952f8df3

But sometimes the tearing takes a while to observe, so there is some chance I've marked a bad commit as good during the bisect.

[jrudess]

The following patch appears to resolve the tearing issues with head of next branch:

diff --git a/src/vsync.c b/src/vsync.c
index 4ea17d2..d680576 100644
--- a/src/vsync.c
+++ b/src/vsync.c
@@ -269,8 +269,8 @@ void (*const VSYNC_FUNCS_DEINIT[NUM_VSYNC])(session_t *ps) = {
  */
 bool vsync_init(session_t *ps) {
   // Mesa turns on swap control by default, undo that
-  if (bkend_use_glx(ps))
-    vsync_opengl_swc_swap_interval(ps, 0);
+  // if (bkend_use_glx(ps))
+  //  vsync_opengl_swc_swap_interval(ps, 0);

   if (ps->o.vsync && VSYNC_FUNCS_INIT[ps->o.vsync]
       && !VSYNC_FUNCS_INIT[ps->o.vsync](ps)) {

[yshui]

@jrudess Are you sure you explicitly enabled vsync in your config file?

[jrudess]

My config is:

opacity-rule = [
    "96:class_g = 'Terminator'",
    "96:class_g = 'dolphin'",
    "96:class_g = 'Lutris'"
];
#To prevent single focused window type from being transparent
#"96:class_g = 'Terminator' && !_NET_WM_STATE@:32a",
#To prevent all focused window from being transparent
#"0:_NET_WM_STATE@:32a *= '_NET_WM_STATE_HIDDEN'"
shadow = true;
shadow-radius = 20;
shadow-offset-x = -20;
shadow-offset-y = -20;
shadow-opacity = 1;
shadow-red = 0.0;
shadow-green = 0.0;
shadow-blue = 0.0;
shadow-exclude = "!I3_FLOATING_WINDOW@:c";
inactive-opacity = 1.0;
active-opacity = 1.0;
frame-opacity = 1.0;
inactive-opacity-override = false;
inactive-dim = 0.0;
blur-kern = "7x7box";
blur-background = false;
blur-background-frame = true;
blur-background-fixed = false;
fading = false;
fade-in-step = 0.05;
fade-out-step = 0.05;
fade-exclude = [ ];
no-fading-openclose = false;
mark-wmwin-focused = true;
mark-ovredir-focused = true;
detect-rounded-corners = false;
detect-client-opacity = false;
refresh-rate = 0;
backend = "glx";
vsync = "opengl";
dbe = false;
focus-exclude = [ "class_g = 'Cairo-clock'" ];
detect-transient = true;
detect-client-leader = true;
invert-color-include = [ ];
glx-copy-from-front = false;
glx-swap-method = "buffer-age";
glx-no-stencil = false;
glx-no-rebind-pixmap = true;
glx-use-gpushader4 = true;
wintypes :
{
  tooltip :
  {
    fade = true;
    shadow = false;
    opacity = 0.95;
    focus = true;
  };
  menu :
  {
    fade = true;
    shadow = false;
  };
  dropdown_menu :
  {
    shadow = false;
    opacity = 0.95;
  };
  popup_menu :
  {
    shadow = false;
    opacity = 0.95;
  };
  utility :
  {
    shadow = false;
  };
  dnd:
  {
    shadow = false;
  };
  dock :
  {
    shadow = false;
    opacity = 1.0;
  };
};

[yshui]

can you try vsync = opengl-swc?

[jrudess]

opengl-swc appears to resolve tearing for me

[yshui]

I guess this is evidence that "vsync = opengl" never worked. People got vsync just because it was enabled by default by Mesa.

[aufkrawall]

Well, it definitely worked for me some time ago. :)
But since it's bugged nowadays and users usually want vsync, perhaps swc should be the default setting?
I also wonder if opengl-oml is actually beneficial for any cases.

[yshui]

perhaps swc should be the default setting?

That is my plan too.

I also wonder if opengl-oml is actually beneficial for any cases.

It is useful for something, but not as a reliable vsync method.

[ghost]

unfortunately, opengl-swc doesn't work well with intel HD 620 with xf86-video-intel driver. If I use opengl and try to record video using ffmpeg, result a good video quality - no tearing. But same ffmpeg command but compton using opengl-swc result a bad tearing video - frames are broken and images totally tear out.

If I don't record a video using ffmpeg, I barely can see the difference, just a little lag of images.

[9ary]

opengl-swc is the same as what mesa previously enabled by default with _all_ vsync methods, including none. Leaving it enabled with other methods would be detrimental to performance (can result in dropped frames).
If you experience tearing with SWC then it's most likely not compton's fault.
All other methods use non-atomic sync+swaps which is prone to breakage and can be detrimental to performance.
SWC (at least on mesa, when using DRI3) queues an asynchronous swap and leaves syncing up to the driver. It will only block if the last frame hasn't already been swapped to the display. This is always what we want.

[aufkrawall]

I also wouldn't suppose that a compositor would be to blame for tearing inside of a recorded video. The capture software should grab the framebuffer before the compositor does anything to it. OBS capture looks normal here with Compton enabled + vsync = swc.

Regarding more lag with swc: Start Compton with --vsync-use-glfinish to reduce it with Mesa drivers.

[yshui]

@Avi-D-coder A couple of things here:

1. Are you sure, that compton --config /dev/null --vsync opengl-swc --backend glx doesn't solve your problem.
2. If a screen capture doesn't record the tearing well, maybe you can point a camera to your screen.
3. Were you able to do a bisect to find the offending commit?

[Avi-D-coder]

Sorry I haven't gotten a chance to bisect yet. compton -CG --config /dev/null --backend glx --vsync opengl-swc --glx-swap-method -1 --glx-no-stencil --vsync-use-glfinish seems to be good enough for now.

There is still an occasional tear when playing a video and scrolling, but the situation improved drastically around the time I updated to linux 4.20.
Thank you.

[maximbaz]

@yshui I've just got an update for v5.0 on Arch Linux and experienced this bug, interestingly the issue didn't reproduce with

compton --config /dev/null --vsync opengl-swc --backend glx

like you suggested, but it did reproduce with compton when my config file only contained two lines:

backend = "glx";
vsync = "opengl-swc";

This lead me to believe that v5 is not properly reading config files. I've seen that you fixed this recently, so I compiled compton from next branch and sure enough the bug no longer reproduce.

Could you please cut off a new release? It looks like a serious regression in v5.0 comparing to v4.0.

[yshui]

@maximbaz compton --diagnostics will tell you which config file is used.

Yeah I will do a release soon.

[maximbaz]

That confirms the issue!

On v5:

* Config file used: /etc/xdg//compton.conf

On next branch:

* Config file used: /home/maximbaz/.config/compton/compton.conf