Picom: Terrible latency with compton v6 compared to v5.1 on AMD

[Ropid]

// The template below is for reporting bugs. For feature requests and others, feel free to delete irrelevant entries.

Platform

Arch Linux

GPU, drivers, and screen setup

AMD RTX 480, Mesa, one 60Hz monitor
xf86-video-amdgpu = 19.0.1
mesa = 19.0.0

Environment

XFCE, xfwm4 4.12.5

Compton version

$ compton --version
v6

$ compton --diagnostics
[ 2019-03-24 00:43:51.769 parse_config_libconfig WARN ] vsync option will take a boolean from now on. "opengl" is interpreted as "true" for compatibility, but this will stop working soon
**Version:** v6

### Extensions:

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

### Misc:

* Use Overlay: Yes
* Config file used: /home/ropid/.config/compton.conf

Compton configuration:

backend = "glx";

glx-no-stencil = true;

glx-no-rebind-pixmap = true;

glx-swap-method = 1;

shadow = true;

shadow-radius = 8;
shadow-offset-x = -8;
shadow-offset-y = -6;
shadow-opacity = 0.35;

shadow-exclude = [
    "class_g = 'Xfwm4'",
    "(class_g = 'Firefox' || class_g = 'Nightly') && window_type = 'utility'",
    "_GTK_FRAME_EXTENTS@:c",
];

inactive-opacity = 1;
active-opacity = 1;
frame-opacity = 1;
inactive-opacity-override = false;

blur-background = false;

fading = false;
fade-in-step = 0.2;
fade-out-step = 0.2;

fade-exclude = [ ];

mark-wmwin-focused = true;
mark-ovredir-focused = true;
use-ewmh-active-win = true;

detect-client-opacity = true;

vsync = "opengl";

unredir-if-possible = true;
unredir-if-possible-exclude = [
  "_NET_WM_BYPASS_COMPOSITOR@:c = 2",
  "class_g = 'MComix'",
  "class_g = 'vlc'",
  "class_g = 'Firefox'",
];

focus-exclude = [ ];

detect-transient = true;
detect-client-leader = true;

wintypes:
{
    tooltip = { full-shadow = true; fade = true; shadow = false; opacity = 0.8; focus = true; };
    dock    = { shadow = false; };
    dnd     = { shadow = false; };
};

Steps of reproduction + Expected behavior + Current Behavior

Grabbing a window and moving it around in circles while staring at the mouse pointer, you can see the window following the mouse pointer at a much larger distance compared to how Compton v5.1 behaved.

In v5.1, the moving window and mouse pointer were very close together. There seemed to be less than one frame of distance between the two. I was guessing this "less than one frame" by moving the mouse pointer in circles fast enough that I could see it jump a good distance from frame to frame on a 60 Hz monitor, for example one inch of distance. When grabbing a window while doing those fast circles, the window was closer to the current mouse pointer position than to the previous mouse pointer position, so I'm thinking it was less than a frame of latency.

My guess would be that v6 is now using what was previously the setting vsync = "opengl-swc". In v5.1, using 'opengl-swc' produced a similar degraded latency as what I'm seeing here right now with v6. In v5.1, using 'opengl' had a much better behavior than 'opengl-swc' for me here.

[yshui]

1. Did vsync = "opengl" _actually_ work for you? Seems it would produce a hard to notice tearing for some people.
2. Can you try --vsync-use-glfinish? That might solve your problem.

[Ropid]

Adding vsync-use-glfinish improves latency a lot for me here. I'm unsure if it's now the same latency as what I had previously with vsync = "opengl".

vsync = "opengl" definitely worked for me. There was never any tearing.

Edit:

Is this right that adding vsync-use-glfinish = true; to the config doesn't work? Only a command line option --vsync-use-glfinish works?

Edit2:

I just installed the old v5.1 Arch package to test and compare and the latency there is much better. So while --vsync-use-glfinish does improve latency on v6, it's still (a lot) worse than how v5 with vsync = "opengl" behaves.

[yshui]

Is this right that adding vsync-use-glfinish = true; to the config doesn't work? Only a command line option --vsync-use-glfinish works?

Yes.

[tiiiecherle]

I can confirm the latency. In a virtualbox running archlinux and open box desktop (macOS host) it is even that bad that double clicking in thunar is impossible because the click is too slow. The right click openbox menu opens only every now end then and the whole desktop is almost unusable.

Any option to try? Running Compton only with compton & and an empty config file. Thanks.

Otherwise downgrading would be the only way for now.

[yshui]

@tiiiecherle Your issue is different, which might be a duplicate of #41

[tiiiecherle]

ok, thanks, but downgrading to 5.1 helps a lot. Still not perfect, but a lot better than 6.0.

[yshui]

So, I bought a new RX590 just to test out this lag.

To me it is pretty much indistinguishable between 5.1 and 6.

[Ropid]

Starting 5.1 like this shows close to no latency for me when moving windows around:

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

When switching to opengl-swc, I seem to get one frame delay added to the window movement:

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

I'm testing by grabbing a window with the mouse pointer and moving it around fast so that the mouse pointer jumps a good distance from frame to frame.

With "opengl-swc", there's a gap between the current mouse pointer position and the moving window. The distance seems to be about how much the mouse pointer jumps from spot to spot on my 60Hz monitor while moving. That's where my "one frame delay" guess comes from.

With "opengl", the window is positioned closer to the current mouse pointer position than the previous mouse pointer position.

Trying to think about what I might have tweaked here for me, I vaguely remember something about Mesa's vblank_mode setting doing something to the latency of compton in past versions (but not with 5.1). Starting compton like this reduced latency in the past:

vblank_mode=1 compton --config /dev/null --backend glx --vsync opengl

[aufkrawall]

I'm really certain that using --vsync-use-glfinish with --vsync = opengl-mswc results in the same frame output delay as with old --vsync = opengl.
I recommend from staying away from forcing anything via vblank_mode, as this likely introduces other problems elsewhere (e.g. Firefox).

[yshui]

I just read about this: http://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-KDE-High-CPU-Fix

~Sounds like NVIDIA finally fixed busy waiting. _Maybe_ we can finally enable glFinish() by default now.~

~Even given KWin's popularity, it still took them 6 years to fix this. Quite sad.~

Edit: Nope, it's a workaround on KWin side. Busy wait still not fixed :(