lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

rzrscm · 2015-06-12 02:09:56

I'm using compton for the sole purpose of preventing screen tearing in videos and games and such, but it's causing a few problems. The first, most common issue is that it seems to cause input lag in some applications, particularly geany (I've tried other GUI text editors, and they have the same problem). The other problem is that the screen doesn't seem to always want to update...This mainly happens when I close a tab on Firefox...It'll still be there until I do something like switch to another tab...My terminal windows also show up as a blank box when I switch from one tag to the tag that they're in until I type inside of them.

I launch it in my xinitrc like so...

compton -GCb --backend glx --paint-on-overlay --vsync opengl-swc --glx-no-stencil

I've read the entire man page and have tried it with different parameters, but nothing seems to work. I also tried xcompmgr, and that didn't solve the problem either. I'm not opposed to using a different (lightweight) compositing manager or another method to prevent screen tearing if these problems can't be solved within compton.

If you need any other info to help me with this, just let me know. Thank you.

Last edited by rzrscm (2015-06-13 05:42:24)

Head_on_a_Stick · 2015-06-12 07:14:52

What is your hardware?

rzrscm · 2015-06-12 15:06:23

My video card is a Nvidia GeForce 8400 GS and I'm using the proprietary (340xx) drivers.

Head_on_a_Stick · 2015-06-12 21:57:10

rzrscm wrote:

Nvidia GeForce 8400 GS

Put that in the thread title to attract the attention of other NVIDIA users (not me)

rzrscm · 2015-06-13 05:42:42

Head_on_a_Stick wrote:

rzrscm wrote:
Nvidia GeForce 8400 GS
Put that in the thread title to attract the attention of other NVIDIA users (not me)

Alright, done...Thanks.

brebs · 2015-06-13 09:58:00

rzrscm wrote:

preventing screen tearing in videos and games and such

Is it needed? Have you tried:

export __GL_SYNC_TO_VBLANK=1
(Set this *before* starting Xorg)

And the vsync option in nvidia-settings.

rzrscm · 2015-06-14 02:43:28

brebs wrote:

rzrscm wrote:
preventing screen tearing in videos and games and such
Is it needed? Have you tried:
export __GL_SYNC_TO_VBLANK=1
(Set this *before* starting Xorg)
And the vsync option in nvidia-settings.

Just tried that and it didn't work. I also just tried making an xorg config file (got this "solution" from https://forum.manjaro.org/index.php?topic=21392.0) and added

Option  "metamodes" "nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }"

and while this seems to fix the problem, it creates a problem where the text in the status bars gets messed up when I change tags (seems like it's trying to show the old text and new text at the same time)...I have to move the mouse over the parts doing it to make it stop.

Last edited by rzrscm (2015-06-14 03:04:45)

brebs · 2015-06-14 09:19:33

What GUI? Try LXDE, which doesn't try to be too clever.

Also see things to try.

rzrscm · 2015-06-15 00:11:23

brebs wrote:

What GUI? Try LXDE, which doesn't try to be too clever.
Also see things to try.

I'm using AwesomeWM...I have a lot invested into it, so I'd rather not change. I tried everything at that link, and none of it seems to solve the problem. I might consider switching to the Nouveau drivers at this point if it would be easier to solve the problem.

avojevlavo · 2015-06-16 04:03:59

Hi, I am compton + awesome+nvidia user too,
try adding this to your xinitrc

nvidia-settings -a InitialPixmapPlacement=0

as sugested in https://bbs.archlinux.org/viewtopic.php?id=179723

it solves the input lag but I have other problems for it, such as no wallpaper as defined in awesome theme and really slow/stutter scroll in firefox.

Write if it works. Cheers

brebs · 2015-06-16 06:15:15

rzrscm wrote:

I'd rather not change

The point is simply to check whether your GUI is to blame.

rzrscm · 2015-06-17 04:00:19

avojevlavo wrote:

Hi, I am compton + awesome+nvidia user too,
try adding this to your xinitrc
nvidia-settings -a InitialPixmapPlacement=0
as sugested in https://bbs.archlinux.org/viewtopic.php?id=179723
it solves the input lag but I have other problems for it, such as no wallpaper as defined in awesome theme and really slow/stutter scroll in firefox.
Write if it works. Cheers

It works exactly as you described...I wonder if there's a fix for the scrolling in Firefox (although I don't feel like I'm noticing a difference at the moment) and wallpaper, though...I assumed that I could simply set the wallpaper with another program, but that doesn't seem to work. Thank you...This is one step forward, but I hope I can solve the problems this solution introduces.

brebs wrote:

The point is simply to check whether your GUI is to blame.

Oh...I have tried other WMs in the past (most recently dwm...and openbox in the past) and had the same problems.

rzrscm · 2015-06-18 22:11:21

So, is there a way to fix the wallpaper with this InitialPixmapPlacement=0 fix? I've tried every method to set my wallpaper that I can think of, and nothing's working.

avojevlavo · 2015-06-28 01:05:31

hi again.
delete the InitialPixmapPlacement line and in your compton config change

backend=glx

to

backend=xr_glx_hybrid

Worked for me, cheers.

randomguy · 2015-06-28 01:27:49

As the previous posters said, try to have your driver manage vsync and then start compton with --vsync none.

rzrscm · 2015-06-29 03:06:12

avojevlavo wrote:

hi again.
delete the InitialPixmapPlacement line and in your compton config change
backend=glx
to
backend=xr_glx_hybrid
Worked for me, cheers.

This seems to solve the lag (although I do still see slight lag that's not there when I have compton disabled), but the problem with the screen not updating still exists and my wallpaper image keeps flashing while I'm scrolling in Firefox...I've started playing around with other glx options, and nothing seems to be helping still...

randomguy wrote:

As the previous posters said, try to have your driver manage vsync and then start compton with --vsync none.

Did this and it doesn't seem to make any difference...I'm going to keep vsync off on compton from now on since the driver is managing vsync, but the problems still exist.

avojevlavo · 2015-06-30 14:11:00

rzrscm wrote:

This seems to solve the lag (although I do still see slight lag that's not there when I have compton disabled), but the problem with the screen not updating still exists and my wallpaper image keeps flashing while I'm scrolling in Firefox...I've started playing around with other glx options, and nothing seems to be helping still...

I noticed that too, but is not that bad I have maybe one flicker per one minute of scrolling, heavy flash/jscript pages seems to make it worse but is still bearable, except for steam where it is flickering badly both in steam client and in games (for example Halflife2 which is unplayable until I disable compton).

rzrscm wrote:

Did this and it doesn't seem to make any difference...I'm going to keep vsync off on compton from now on since the driver is managing vsync, but the problems still exist.

randomguy wrote:

As the previous posters said, try to have your driver manage vsync and then start compton with --vsync none.

I thought the whole point of running compton with vsync is to prevent tearing while playing videos. Am I wrong? Will try to disable to test it.

Chazza · 2015-06-30 14:59:56

avojevlavo wrote:

I thought the whole point of running compton with vsync is to prevent tearing while playing videos. Am I wrong? Will try to disable to test it.

The compositor, be it Compton, Xfwm, Compiz, Mutter etc should indeed be preventing tearing with vsync. However, for many compositors, the vsync implementation doesn't seem to work terribly well. The Xfwm compositor with vsync on certainly doesn't prevent all tearing for me - especially with fullscreen videos (Intel graphics).

Intel man page wrote:

Option "TearFree" "boolean"
Disable or enable TearFree updates. This option forces X to perform all rendering to a backbuffer prior to updating the actual dis‐
play. It requires an extra memory allocation the same size as a framebuffer, the occasional extra copy, and requires Damage track‐
ing. Thus enabling TearFree requires more memory and is slower (reduced throughput) and introduces a small amount of output latency,
but it should not impact input latency. However, the update to the screen is then performed synchronously with the vertical refresh
of the display so that the entire update is completed before the display starts its refresh. That is only one frame is ever visible,
preventing an unsightly tear between two visible and differing frames. Note that this replicates what the compositing manager should
be doing, however TearFree will redirect the compositor updates (and those of fullscreen games) directly on to the scanout thus
incurring no additional overhead in the composited case. Also note that not all compositing managers prevent tearing, and if the
outputs are rotated, there will still be tearing without TearFree enabled.

rzrscm · 2015-06-30 17:15:15

Chazza wrote:

The compositor, be it Compton, Xfwm, Compiz, Mutter etc should indeed be preventing tearing with vsync. However, for many compositors, the vsync implementation doesn't seem to work terribly well. The Xfwm compositor with vsync on certainly doesn't prevent all tearing for me - especially with fullscreen videos (Intel graphics).

I don't understand what compton's even doing at this point...I get obvious screen tearing without it, but no screen tearing with it running even with vsync disabled.

avojevlavo · 2015-06-30 17:59:31

heh, looks like I figured it out, no tearing, no flicker, no lag or delay, will test some more

nvidiaconf with enabled vsync option
compton settings bellow look for sections other and glx backend

# Shadow
shadow = false;
no-dnd-shadow = true;
no-dock-shadow = true;
clear-shadow = true;
shadow-radius = 10;
shadow-offset-x = 10;
shadow-offset-y = 10;
# shadow-opacity = 0.7;
# shadow-red = 0.0;
# shadow-green = 0.0;
# shadow-blue = 0.0;
shadow-exclude = [ "name = 'Notification'", "class_g = 'Conky'", "class_g ?= 'Notify-osd'", "class_g = 'Cairo-clock'" ];
# shadow-exclude = "n:e:Notification";
shadow-ignore-shaped = false;
# shadow-exclude-reg = "x10+0+0";
# xinerama-shadow-crop = true;

# Opacity
# menu-opacity = 0.8;
# inactive-opacity = 0.7;
# active-opacity = 0.8;
frame-opacity = 0.5;
inactive-opacity-override = false;
alpha-step = 0.01;
# inactive-dim = 0.2;
# inactive-dim-fixed = true;
blur-background = true;
blur-background-frame = false;
blur-kern = "11x11gaussian"
# blur-kern = "5,5,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1"
# blur-background-fixed = true;
blur-background-exclude = [ "window_type = 'dock'", "window_type = 'desktop'" ];
# opacity-rule = [ "80:class_g = 'URxvt'" ];

# Fading
fading = true;
# fade-delta = 30;
fade-in-step = 0.03;
fade-out-step = 0.03;
# no-fading-openclose = true;
fade-exclude = [ ];

# Other
backend = "glx"
mark-wmwin-focused = true;
mark-ovredir-focused = true;
# use-ewmh-active-win = true;
detect-rounded-corners = true;
detect-client-opacity = true;
refresh-rate = 60;
vsync = "none";
dbe = false;
paint-on-overlay = true;
# sw-opti = true;
unredir-if-possible = true;
# unredir-if-possible-delay = 5000;
# unredir-if-possible-exclude = [ ];
focus-exclude = [ "class_g = 'Cairo-clock'" ];
detect-transient = true;
detect-client-leader = true;
invert-color-include = [ ];
# resize-damage = 1;

# GLX backend
glx-no-stencil = true;
glx-copy-from-front = false;
#glx-use-copysubbuffermesa = true;
glx-no-rebind-pixmap = true;
glx-swap-method = "undefined";
glx-use-gpushader4 = true;

# Window type settings
wintypes:
{
  tooltip = { fade = true; shadow = false; opacity = 0.75; focus = true; };
};

Chazza · 2015-06-30 21:44:30

rzrscm wrote:

Chazza wrote:
The compositor, be it Compton, Xfwm, Compiz, Mutter etc should indeed be preventing tearing with vsync. However, for many compositors, the vsync implementation doesn't seem to work terribly well. The Xfwm compositor with vsync on certainly doesn't prevent all tearing for me - especially with fullscreen videos (Intel graphics).
I don't understand what compton's even doing at this point...I get obvious screen tearing without it, but no screen tearing with it running even with vsync disabled.

I found the following quite a good read when it comes to understanding screen tearing and vsync: https://www.avforums.com/threads/brilli … zz.774541/

The information about buffering is relevant to compositors because that's essentially what a compositor is doing - storing the graphical content in an offscreen buffer where it can be composited (hence the name) and then displayed as a visible frame.

brebs · 2015-06-30 22:04:54

rzrscm wrote:

sole purpose of preventing screen tearing

Nvidia thread might be relevant.

Try this workaround for xorg-server bug:

sed -e "s:disableBackingStore = FALSE:disableBackingStore = TRUE:" -i dix/window.c

randomguy · 2015-07-10 15:04:57

You could also try to play around with glx-swap-method setting, "undefined" is supposed to be the slowest and I can confirm that it made quite a difference for me when I set it to "buffer-age". This is not supported by all drivers and my experience is on an Intel chipset. Some explanation from a compton.conf I found on the web somewhere:

# GLX backend: GLX buffer swap method we assume.
# Could be undefined (0), copy (1), exchange (2), 3-6, or buffer-age (-1).
# undefined is the slowest and the safest, and the default value.
# copy is fastest, but may fail on some drivers,
# 2-6 are gradually slower but safer (6 is still faster than 0).
# Usually, double buffer means 2, triple buffer means 3.
# buffer-age means auto-detect using GLX_EXT_buffer_age, supported by some drivers.
# Useless with --glx-use-copysubbuffermesa.
# Partially breaks --resize-damage.
# Defaults to undefined.
#glx-swap-method = "copy";
glx-swap-method = "buffer-age"

rzrscm · 2015-07-16 09:16:22

randomguy wrote:

You could also try to play around with glx-swap-method setting, "undefined" is supposed to be the slowest and I can confirm that it made quite a difference for me when I set it to "buffer-age". This is not supported by all drivers and my experience is on an Intel chipset. Some explanation from a compton.conf I found on the web somewhere:
# GLX backend: GLX buffer swap method we assume.
# Could be undefined (0), copy (1), exchange (2), 3-6, or buffer-age (-1).
# undefined is the slowest and the safest, and the default value.
# copy is fastest, but may fail on some drivers,
# 2-6 are gradually slower but safer (6 is still faster than 0).
# Usually, double buffer means 2, triple buffer means 3.
# buffer-age means auto-detect using GLX_EXT_buffer_age, supported by some drivers.
# Useless with --glx-use-copysubbuffermesa.
# Partially breaks --resize-damage.
# Defaults to undefined.
#glx-swap-method = "copy";
glx-swap-method = "buffer-age"

I've tried this...buffer-age and copy both make everything glitchy, while other settings like exchange just make it seem laggier. I've gone through everything in this thread and read all of the material and still haven't found a suitable solution that works.

I'm wondering if this problem can be solved by getting a new video card? I've been considering upgrading, anyway.

donovan · 2017-08-29 18:49:48

Was this problem ever solved?

I'm using i3 + compton + nvidia. All terminals have input lag.

Cinnamon works fine though.

Arch Linux

#1 2015-06-12 02:09:56

lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#2 2015-06-12 07:14:52

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#3 2015-06-12 15:06:23

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#4 2015-06-12 21:57:10

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#5 2015-06-13 05:42:42

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#6 2015-06-13 09:58:00

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#7 2015-06-14 02:43:28

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#8 2015-06-14 09:19:33

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#9 2015-06-15 00:11:23

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#10 2015-06-16 04:03:59

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#11 2015-06-16 06:15:15

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#12 2015-06-17 04:00:19

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#13 2015-06-18 22:11:21

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#14 2015-06-28 01:05:31

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#15 2015-06-28 01:27:49

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#16 2015-06-29 03:06:12

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#17 2015-06-30 14:11:00

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#18 2015-06-30 14:59:56

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#19 2015-06-30 17:15:15

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#20 2015-06-30 17:59:31

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#21 2015-06-30 21:44:30

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#22 2015-06-30 22:04:54

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#23 2015-07-10 15:04:57

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#24 2015-07-16 09:16:22

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

#25 2017-08-29 18:49:48

Re: lag and other problems with compton in awesome (Nvidia GeForce 8400GS)

Board footer