You are not logged in.

#1 2017-09-27 13:29:51

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 792

Compton System-wide configuration settings.

As discussed in Development and Suggestions Compton Startup Options and bl-compositor the Bunsenlabs developers are discussing splitting the machine specific configurations off and placing them into /etc. These are the settings that specify the backend for compton to use, etc. I agreed to try and do some testing and map out what works and what doesn't for various machine configurations.

It appears to me that compton's performance is highly dependent on the video driver that is in use. It might be impossible to get perfect compositing for every machine out in the wild. This discussion can serve as a baseline for establishing sane defaults and optimizing compton. This is a complex topic and help and input would be greatly appreciated.

I think to start out, perhaps we should show the video card, the driver that is in use (i.e. nouveua, nvidia-driver, fglrx, etc.) To do this I used:

lspci -vnn | grep VGA -A 12

This gives me output like the following:

00:02.0 VGA compatible controller [0300]: InnoTek Systemberatung GmbH VirtualBox Graphics Adapter [80ee:beef] (prog-if 00 [VGA controller])
	Flags: bus master, fast devsel, latency 0, IRQ 18
	Memory at e0000000 (32-bit, prefetchable) [size=128M]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Kernel driver in use: vboxvideo
	Kernel modules: vboxvideo

I used the compton.conf file presented in HOw to switch to Compton for Beautiful Tear Free Compositing in XFCE I will use this file as my reference while working on compton's numerous options.

Please note, this post is not intended to reflect compositing options that would be user specific such as shadows and blurs, etc.

Offline

#2 2017-09-27 13:33:38

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 792

Re: Compton System-wide configuration settings.

Compton in Virtualbox

Here is the machine specific setting that I used to get compositing  working in Virtualbox. The comments also annotate what didn't work so as to avoid lockups, etc.

#################################
# These options are what I consider to be machine specific options
# It would be useful for the community to look these options over.
# Machine specific options should be listed in /etc
########################################################################
#
# Backend
#
########################################################################
# Backend to use: "xrender" or "glx".
# GLX backend is typically much faster but depends on a sane driver.

backend = "glx";

########################################################################
#
# --vsync opengl does NOT cause lag with Nvidia vsync disabled. I can turn 
# Nvidia vsync on after launching compton with --vsync opengl and I do not 
# get lag, but if I do it in the other order, I do get lag. 
# It still tears though in both situations.
# I have seen various reports like the above. Some nvidia drivers
# seem to create significant slowdowns.
# Sometimes it might be useful to visit nvidia-settings if running
# nvidia's proprietary drivers.
#
########################################################################
#
# This is the compton.conf I setup for my Surfacebook Pro IV running
# Bunsenlabs in Virtualbox. Virtualbox is limited to opengl 2.1 when
# using the guest additions.
#
########################################################################

########################################################################
#
# GLX backend
#
########################################################################

glx-no-stencil = true;

# GLX backend: Copy unmodified regions from front buffer instead of redrawing them all.
# My tests with nvidia-drivers show a 10% decrease in performance when the whole screen is modified,
# but a 20% increase when only 1/4 is.
# My tests on nouveau show terrible slowdown.
# Useful with --glx-swap-method, as well.
#glx-copy-from-front = false;

# GLX backend: Use MESA_copy_sub_buffer to do partial screen update.
# My tests on nouveau shows a 200% performance boost when only 1/4 of the screen is updated.
# May break VSync and is not available on some drivers.
# Overrides --glx-copy-from-front.
# glx-use-copysubbuffermesa = true;

# GLX backend: Avoid rebinding pixmap on window damage.
# Probably could improve performance on rapid window content changes, but is known to break things on some drivers (LLVMpipe).
# Recommended if it works.
#glx-no-rebind-pixmap = true; < -- This option causes lockups in Virtualbox.

# 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.
########################################################################
#
# I am using double-buffering here. This is a typical scenarion wherein the
# screen is drawn into memory before being painted on the screen. 
# Better machines might want to use triple buffering if they have native
# hardware support for it on their graphics card. 
#
########################################################################
glx-swap-method = "exchange";

# Specify refresh rate of the screen.
# If not specified or 0, compton will try detecting this with X RandR extension.
refresh-rate = 0;

# Set VSync method. VSync methods currently available:
# none: No VSync
# drm: VSync with DRM_IOCTL_WAIT_VBLANK. May only work on some 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 SGI_swap_control OpenGL extension. Only work on some drivers. Works only with GLX backend. 
# Known to be most effective on many drivers. Does not actually control paint timing, only buffer swap is affected, so it doesn’t have the 
# effect of --sw-opti unlike other methods. Experimental.
# opengl-mswc: Try to VSync with MESA_swap_control OpenGL extension. Basically the same as opengl-swc above, except the extension we use.
# (Note some VSync methods may not be enabled at compile time.)

# None of the above vsync methods worked for me in Virtualbox.
vsync = "none";

# Enable DBE painting mode, intended to use with VSync to (hopefully) eliminate tearing.
# Reported to have no effect, though.
dbe = false;
# Painting on X Composite overlay window. Recommended.
paint-on-overlay = true;

# Limit compton to repaint at most once every 1 / refresh_rate second to boost performance.
# This should not be used with --vsync drm/opengl/opengl-oml as they essentially does --sw-opti's job already,
# unless you wish to specify a lower refresh rate than the actual value.
sw-opti = false;

# Unredirect all windows if a full-screen opaque window is detected, to maximize performance for full-screen windows, like games.
# Known to cause flickering when redirecting/unredirecting windows.
# paint-on-overlay may make the flickering less obvious.
unredir-if-possible = true;

Virtualbox's guest additions are built against opengl 2.1. We are currently at version 4 or so. Aggressive settings will cause instability and lockups. As a side note: this is the first time I have actually had compositing working in Virtualbox.

EDIT: These current settings are interfering with both scrot and xfce4-screenshooter. I have to turn off compositing if I want to scrot. This may be a limitation I have to live with when using Virtualbox, however.

Last edited by tknomanzr (2017-09-28 22:51:09)

Offline

#3 2017-09-28 03:48:09

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 3,409
Website

Re: Compton System-wide configuration settings.

@tknomanzr Many thanks for starting this!
Other users - if you add your own hardware details and what compton settings worked best for you, we can build up a useful reference. cool


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#4 2017-09-28 11:32:38

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 792

Re: Compton System-wide configuration settings.

I will add my desktop later today.

Offline

#5 2017-09-28 12:21:00

Bearded_Blunder
Member
Registered: 2015-09-29
Posts: 363

Re: Compton System-wide configuration settings.

johnraff wrote:

@tknomanzr Many thanks for starting this!
Other users - if you add your own hardware details and what compton settings worked best for you, we can build up a useful reference. cool

Other User wrote:

Um, some instructions for how to determine what "worked best" would be useful here.

I mean, I'm finding everything OK allowing that the machine is old in helium-dev as shipped, so how will I know what's "better"?
I lack the monitor to see what HD video looks like...

For completeness: 

lspci -vnn | grep VGA -A 12 wrote:
00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02) (prog-if 00 [VGA controller])
	Subsystem: Dell 82945G/GZ Integrated Graphics Controller [1028:01ad]
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at feb00000 (32-bit, non-prefetchable) [size=512K]
	I/O ports at e898 [size=8]
	Memory at e0000000 (32-bit, prefetchable) [size=256M]
	Memory at feac0000 (32-bit, non-prefetchable) [size=256K]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Kernel driver in use: i915
	Kernel modules: i915

Blessed is he who expecteth nothing, for he shall not be disappointed...

Offline

#6 2017-09-28 13:07:07

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 792

Re: Compton System-wide configuration settings.

^ So helium-dev compositing works on the i915. This is useful to know as that particular chip is known to have its quirks.

As an additional note, sometimes switching the backend to xrender will actually improve performance because it is better optimized to handle 2d painting that Opengl is. Additionally, sometimes buggy drivers may require an xrender backend, I have seen threads across the internet for nvidia-proprietary, nouveau, and fglrx having issues here and there. I have had issues with older Intel cards in the past as well.

Also, at times, a full screen window will not unredir properly and appear to hang This is fairly common to older games running in wine, for instance. Your option there is to disable compositing. In that case, I would probably start the game via a wrapper script that disabled compositing prior to running the game.

I used to get fairly bad tearing in Firefox. That issue seems to have been resolved somewhere along the line, most likely with the inclusion of the vdpau drivers.

I have a feeling that this will end up a container that documents edge cases. I think most people don't mess with compton much unless things break. However, from a user perspective, I am pondering changing the shadow colors to a dark jade green in helium-dev to better match the color scheme it is using. The black shadows work but a bit of green in them would look nice, I think.

Perhaps splitting off the difficult hardware parts will encourage users to tinker with compton more. Having some idea what works and what doesn't on the the hardware side would be nice however. For instance, I have never seen glx-no-rebind-pixmap actually work. It is very likely that it has to do with how openbox paints windows to the screen.

In terms of performance testing, compton has some built-in options. I was going to attempt to run phoronix benchmarks on compton. However, this requires libraries I don't have, despite the test suite itself being in Stable, the -dev libraries it requires for that test are not. It might be possible for someone with more build experience to get it running but at the moment, I am stuck, so everything becomes quite subjective. If things work without locking up or tearing, I am happy.

As a final note, when compton starts to become unstable, it will output warnings to ~/.xsession-errors. I usually tail -f that file while messing around with compton's options. The warnings will typically look like this:

glx_bind_pixmap(0x0081fdcf): Failed to query Pixmap info.
win_paint_win(0x01c00003): Failed to bind texture. Expect troubles.
win_paint_win(0x01c00003): Missing painting data. This is a bad sign.

For compton's built-in benchmarking, I would refer you to:
Compton Performance Guide, from Compton's github wiki
To keep things simpler, I started off just documenting what works and what doesn't.

Offline

#7 2017-09-29 05:07:42

Head_on_a_Stick
Moderator
From: London
Registered: 2015-09-29
Posts: 7,383
Website

Re: Compton System-wide configuration settings.

Bearded_Blunder wrote:

how will I know what's "better"?

The basic function of the compositor is pure eye candy — it adds (true) transparency, drop shadows and fading — and so the "best" is what you personally like the look of.

I would add a note of caution here that compton should *not* be used to control vsync (ie, screen tearing) unless the native methods availble via the video drivers do not work.

From the developers (added emphasis):

First of all, compton cannot do VSync better than your driver could. For vesa and other pure-software or broken drivers, or when you turned off the hardware acceleration in your driver, you shouldn’t expect much about VSync.

https://github.com/chjj/compton/wiki/vsync-guide


"The first principle is that you must not fool yourself - and you are the easiest person to fool" — Richard Feynman

Forum Rules   •   How to report a problem   •   bunsenlabs(7)

Offline

#8 2017-09-29 22:40:00

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 792

Re: Compton System-wide configuration settings.

tknomanzr wrote:

Compton in Virtualbox

Here is the machine specific setting that I used to get compositing  working in Virtualbox. The comments also annotate what didn't work so as to avoid lockups, etc.

#################################
# These options are what I consider to be machine specific options
# It would be useful for the community to look these options over.
# Machine specific options should be listed in /etc
########################################################################
#
# Backend
#
########################################################################
# Backend to use: "xrender" or "glx".
# GLX backend is typically much faster but depends on a sane driver.

backend = "glx";

########################################################################
#
# --vsync opengl does NOT cause lag with Nvidia vsync disabled. I can turn 
# Nvidia vsync on after launching compton with --vsync opengl and I do not 
# get lag, but if I do it in the other order, I do get lag. 
# It still tears though in both situations.
# I have seen various reports like the above. Some nvidia drivers
# seem to create significant slowdowns.
# Sometimes it might be useful to visit nvidia-settings if running
# nvidia's proprietary drivers.
#
########################################################################
#
# This is the compton.conf I setup for my Surfacebook Pro IV running
# Bunsenlabs in Virtualbox. Virtualbox is limited to opengl 2.1 when
# using the guest additions.
#
########################################################################

########################################################################
#
# GLX backend
#
########################################################################

glx-no-stencil = true;

# GLX backend: Copy unmodified regions from front buffer instead of redrawing them all.
# My tests with nvidia-drivers show a 10% decrease in performance when the whole screen is modified,
# but a 20% increase when only 1/4 is.
# My tests on nouveau show terrible slowdown.
# Useful with --glx-swap-method, as well.
#glx-copy-from-front = false;

# GLX backend: Use MESA_copy_sub_buffer to do partial screen update.
# My tests on nouveau shows a 200% performance boost when only 1/4 of the screen is updated.
# May break VSync and is not available on some drivers.
# Overrides --glx-copy-from-front.
# glx-use-copysubbuffermesa = true;

# GLX backend: Avoid rebinding pixmap on window damage.
# Probably could improve performance on rapid window content changes, but is known to break things on some drivers (LLVMpipe).
# Recommended if it works.
#glx-no-rebind-pixmap = true; < -- This option causes lockups in Virtualbox.

# 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.
########################################################################
#
# I am using double-buffering here. This is a typical scenarion wherein the
# screen is drawn into memory before being painted on the screen. 
# Better machines might want to use triple buffering if they have native
# hardware support for it on their graphics card. 
#
########################################################################
glx-swap-method = "exchange";

# Specify refresh rate of the screen.
# If not specified or 0, compton will try detecting this with X RandR extension.
refresh-rate = 0;

# Set VSync method. VSync methods currently available:
# none: No VSync
# drm: VSync with DRM_IOCTL_WAIT_VBLANK. May only work on some 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 SGI_swap_control OpenGL extension. Only work on some drivers. Works only with GLX backend. 
# Known to be most effective on many drivers. Does not actually control paint timing, only buffer swap is affected, so it doesn’t have the 
# effect of --sw-opti unlike other methods. Experimental.
# opengl-mswc: Try to VSync with MESA_swap_control OpenGL extension. Basically the same as opengl-swc above, except the extension we use.
# (Note some VSync methods may not be enabled at compile time.)

# None of the above vsync methods worked for me in Virtualbox.
vsync = "none";

# Enable DBE painting mode, intended to use with VSync to (hopefully) eliminate tearing.
# Reported to have no effect, though.
dbe = false;
# Painting on X Composite overlay window. Recommended.
paint-on-overlay = true;

# Limit compton to repaint at most once every 1 / refresh_rate second to boost performance.
# This should not be used with --vsync drm/opengl/opengl-oml as they essentially does --sw-opti's job already,
# unless you wish to specify a lower refresh rate than the actual value.
sw-opti = false;

# Unredirect all windows if a full-screen opaque window is detected, to maximize performance for full-screen windows, like games.
# Known to cause flickering when redirecting/unredirecting windows.
# paint-on-overlay may make the flickering less obvious.
unredir-if-possible = true;

Virtualbox's guest additions are built against opengl 2.1. We are currently at version 4 or so. Aggressive settings will cause instability and lockups. As a side note: this is the first time I have actually had compositing working in Virtualbox.

EDIT: These current settings are interfering with both scrot and xfce4-screenshooter. I have to turn off compositing if I want to scrot. This may be a limitation I have to live with when using Virtualbox, however.

I need to add that in order to get Compton working in Virtualbox, I had to compile compton's main branch from source.

compton --version
git-v0.1_beta2-87-g316eac0-2017-04-30

Somehow I had forgotten that I had built it from source. SO the real question is, are you willing to backport compton for the latest features and bug-fixes or would you prefer what is in stable? If the latter, then this config file may or may not work. I would  eed to do more testing to be sure.
Things I now know:

  1. Compton does not seem to work in Virtualbox unless I compile the main branch from it's git.

  2. BL's default compton.conf does not work at all in Virtualbox. <-- I had to use compton --config ~/.config/compton.conf in autostart to get it running. This means that compton restart in the openbox menu is likely also not working.

  3. The above config does enable compositing. However, I cannot screenshot anything without disabling compositing, so you will have to take my word for it on this.

Offline

#9 2017-09-29 22:53:42

twoion
ほやほや
Registered: 2015-08-10
Posts: 1,895
Website

Re: Compton System-wide configuration settings.

^ The compton build available in BL jessie-backport https://www.bunsenlabs.org/repoidx.html … escription  is also the latest compton, feature-wise. All commits since 2015 were purely cosmetic and didn't touch anything of significance, hence I didn't update the package.


Where time just endlessly spins…

Online

#10 2017-09-30 00:58:19

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 792

Re: Compton System-wide configuration settings.

I did check the git history and saw very little activity. It is good to know about the backport, however.

Offline

#11 2017-09-30 03:07:10

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 3,409
Website

Re: Compton System-wide configuration settings.

Re: compton in virtualbox.
Everything worked for me with the standard compton and default settings after disabling 3D acceleration.
(VB Settings>Display)
Screenshots, also no problem:
2V7L166m.png
3D acceleration is a security risk anyway because it allows the guest direct access to the host's hardware. If the performance hit is acceptable disabling it is the simple fix.

VB support for 3D acceleration and opengl seems to be poor.
https://www.virtualbox.org/ticket/12746 (claims to be "fixed")
https://www.virtualbox.org/manual/ch04.html#guestadd-3d


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#12 2017-10-03 17:15:34

Head_on_a_Stick
Moderator
From: London
Registered: 2015-09-29
Posts: 7,383
Website

Re: Compton System-wide configuration settings.

Brief observations from a fresh Helium-dev install on Intel Haswell (i5-4330M/HD4600) hardware:

The stock setting (`compton --vsync opengl`) does help with screen tearing but it is still there; `--vsync opengl --backend opengl-mswc` is better but still not perfect.

My preferred solution is to remove the `--vsync opengl` flag completely and use the Intel DDX driver's in-built TearFree option instead, that works best of all.

I would propose dropping the vsync flag entirely as this seems to be the "correct" thing to do but then our stock desktop would tear badly on Intel hardware unless the driver options are changed.

My AMD laptop doesn't suffer with tearing and so does not need the vsync control at all and whilst I have no NVIDIA hardware available to test, those cards have their own method to deal with the problem (https://wiki.archlinux.org/index.php/NV … en_tearing).


"The first principle is that you must not fool yourself - and you are the easiest person to fool" — Richard Feynman

Forum Rules   •   How to report a problem   •   bunsenlabs(7)

Offline

#13 2017-10-03 18:04:36

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 792

Re: Compton System-wide configuration settings.

The stock Helium-dev compton configuration seems to work fine for me with nvidia proprietary. I didn't notice any problems with the noveau drivers either. The main thing with nvidia's proprietary drivers will be that some things in nvidia-settings will not work well with compton.
For reference:

tknomanzr@wtfbox:/usr/local/bin$ lspci -vnn | grep VGA -A 12
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 980] [10de:13c0] (rev a1) (prog-if 00 [VGA controller])
	Subsystem: eVga.com. Corp. GM204 [GeForce GTX 980] [3842:2983]
	Physical Slot: 4
	Flags: bus master, fast devsel, latency 0, IRQ 43, NUMA node 0
	Memory at fa000000 (32-bit, non-prefetchable) [size=16M]
	Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Memory at f0000000 (64-bit, prefetchable) [size=32M]
	I/O ports at e000 [size=128]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: nvidia
	Kernel modules: nvidia

Offline

#14 2017-10-04 06:07:38

Head_on_a_Stick
Moderator
From: London
Registered: 2015-09-29
Posts: 7,383
Website

Re: Compton System-wide configuration settings.

tknomanzr wrote:

The stock Helium-dev compton configuration seems to work fine for me with nvidia proprietary. I didn't notice any problems with the noveau drivers either.

Do you have any screen tearing problems if compton's "--vsync opengl" option is removed?

That is the current EXECCOMP+ value in /usr/bin/bl-compositor if hardware acceleration is supported; personally I do not think we should apply compton's vsync methods at all [1] but they do seem to be a necessary evil, for Intel graphics cards at least.

[1] Not only is compton's vsync method crude and inefficient, it also induces a "lag" when dragging windows around the desktop that some (me) find intolerable.


"The first principle is that you must not fool yourself - and you are the easiest person to fool" — Richard Feynman

Forum Rules   •   How to report a problem   •   bunsenlabs(7)

Offline

#15 2017-12-06 08:34:41

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 3,409
Website

Re: Compton System-wide configuration settings.

(Revisiting compton.)

twoion wrote:

^ The compton build available in BL jessie-backport https://www.bunsenlabs.org/repoidx.html … escription  is also the latest compton, feature-wise. All commits since 2015 were purely cosmetic and didn't touch anything of significance, hence I didn't update the package.

The debian Stretch version seems to go one commit further, to 2343e4b, a minor bugfix, but anyway in Helium we can just use that one I guess.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#16 2017-12-06 09:35:43

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 3,409
Website

Re: Compton System-wide configuration settings.

A nice check for vertical tearing:

kafran wrote:

The test I did was to watch this video https://launchpadlibrarian.net/27475515 … _60fps.mp4

It's flashing green and red fast enough that it should look like a flickery orange colour. If you see bits of green or red, then try tweaking something.

---
My GPU: Nvidia GeForce GT 220
using the proprietary Nvidia driver 340.102, installed via Debian.

john@bunsen1:~$ lspci -vnn | grep VGA -A 12
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT216 [GeForce GT 220] [10de:0a20] (rev a2) (prog-if 00 [VGA controller])
	Flags: bus master, fast devsel, latency 0, IRQ 45
	Memory at fa000000 (32-bit, non-prefetchable) [size=16M]
	Memory at d0000000 (64-bit, prefetchable) [size=256M]
	Memory at ce000000 (64-bit, prefetchable) [size=32M]
	I/O ports at dc00 [size=128]
	[virtual] Expansion ROM at fbe80000 [disabled] [size=512K]
	Capabilities: <access denied>
	Kernel driver in use: nvidia

Compton
No startup options at all seemed OK generally, but showed plenty of nasty red/green stripes on above video.
Tried some entries in compton.conf:
backend = "glx"; made it worse, if anything.
vsync = "opengl"; much better.
Both above was much worse again, so glx seems to be out here.

Head_on_a_Stick wrote:

The stock setting (`compton --vsync opengl`) does help with screen tearing but it is still there; `--vsync opengl --backend opengl-mswc` is better...

This made compton crash for me:

parse_backend("opengl-mswc`"): Invalid backend argument.

Maybe you meant `--vsync opengl-mswc`?
But that fails for me too with "vsync_opengl_mswc_init(): Failed to get MESA_swap_control function."

No other vsync options worked, and I couldn't find any other settings which improved on `vsync = "opengl";`


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#17 2017-12-06 18:25:40

Head_on_a_Stick
Moderator
From: London
Registered: 2015-09-29
Posts: 7,383
Website

Re: Compton System-wide configuration settings.

johnraff wrote:
Head_on_a_Stick wrote:

The stock setting (`compton --vsync opengl`) does help with screen tearing but it is still there; `--vsync opengl --backend opengl-mswc` is better...

Ooops, transposition error...

Should have been:

compton --backend glx --vsync opengl-mswc &

That's what I'm using now, although thinking about it I've just installed xf86-video-intel so I really should use the built-in TearFree option instead.

@johnraff, please read the sections in the compton man page that describe the --vsync and --backend options, they are complicated and there is no clear "best" option (IMO).

Also, have you tried ditching the proprietary drivers?

They are buggy as heck if my experience on various forums is anything to go by and nouveau is apparently very good indeed in Debian stretch.

I think your experiences do reinforce my argument that no vsync options at all should be applied to compton, do you agree?

My Intel HD4600 has the TearFree option (radeon & amdgpu have something similar) and your Mr. Blobby NVIDIA card has the full force composition pipeline to deal with tearing, both are significantly more effective than comtpon in that respect.

Last edited by Head_on_a_Stick (2017-12-06 19:41:31)


"The first principle is that you must not fool yourself - and you are the easiest person to fool" — Richard Feynman

Forum Rules   •   How to report a problem   •   bunsenlabs(7)

Offline

#18 2017-12-07 03:13:52

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 3,409
Website

Re: Compton System-wide configuration settings.

Head_on_a_Stick wrote:

@johnraff, please read the sections in the compton man page that describe the --vsync and --backend options, they are complicated and there is no clear "best" option (IMO).

Indeed. I have read that stuff (and the github vsync page) but I was mostly looking at the Jessie manual - Stretch compton has more options and explanations. And a lot of it is Greek to me I'm afraid.

Also, have you tried ditching the proprietary drivers?
They are buggy as heck if my experience on various forums is anything to go by and nouveau is apparently very good indeed in Debian stretch.

I'm still on Jessie, and I always try the default stuff before installing anything extra. There was some reason, which I now forget, for switching to the Nvidia driver. I'm looking forward to not having to do that on Stretch.

I think your experiences do reinforce my argument that no vsync options at all should be applied to compton, do you agree?

...er, no.

johnraff wrote:

Tried some entries in compton.conf:
backend = "glx"; made it worse, if anything.
vsync = "opengl"; much better.

For my hardware, under Jessie, `vsync = "opengl";` seems to be the best choice. I can't claim to have been exhaustively through every single combination of backend and vsync settings, but I've tried a lot of them.

your NVIDIA card has the full force composition pipeline to deal with tearing

CompositionPipeline does not seem to be available with my card & driver. The gui shows no such option as described on the Arch Wiki, and using the terminal:

john@bunsen1:~$ nvidia-settings -V all --assign CurrentMetaMode="nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }"


john@bunsen1:~$ nvidia-settings --query CurrentMetaMode

  Attribute 'CurrentMetaMode' (bunsen1:0.0): id=50, switchable=no, source=nv-control ::
  DPY-2: nvidia-auto-select @1440x900 +0+0 {ViewPortIn=1440x900,
  ViewPortOut=1440x900+0+0}

john@bunsen1:~$ nvidia-settings --query all | grep -i composition
john@bunsen1:~$ 

Also:

compton vsync guide wrote:

It’s reported that with newer nvidia-drivers, putting the following line under the Section "Screen" of xorg.conf stops tearing:

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

However it’s indicated that it introduces huge (~30%) performance loss on some OpenGL applications.

The Arch Wiki is a wonderful resource, but Arch do seem to be always looking forward, and pay less attention to older hardware. My machine (4GB, 4-core) is hardly archaic and BL is definitely a choice for machines that would struggle with bigger DEs.

While I agree with the decision not to enable vsync with compton by default in BL, for me: vsync = "opengl" seems to be the only option - unless there's some obscure combination of settings waiting to be discovered.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#19 2017-12-07 05:16:45

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 792

Re: Compton System-wide configuration settings.

I am still a fan of sane defaults here. All of my experimentation has always lead me back to believing that the compton.conf we have used in the past is pretty much that sane default. Granted, I can already tell you that it does not work on ALL video hardware but short of pure software compositing (which would work horribly on low-end hardware), I don't think we will ever find a configuration that will.

Offline

#20 2017-12-07 06:51:39

Head_on_a_Stick
Moderator
From: London
Registered: 2015-09-29
Posts: 7,383
Website

Re: Compton System-wide configuration settings.

johnraff wrote:

I think your experiences do reinforce my argument that no vsync options at all should be applied to compton, do you agree?

...er, no.

[...]

While I agree with the decision not to enable vsync with compton by default in BL

I am confused.

My proposal is that in the stock BunsenLabs desktop compton should be run without any --backend or --vsync flags at all, do you agree with that?

I think this is the best option for us because applying any given set of flags uniformly may be advantageous for one set of hardware but deleterious for another.


"The first principle is that you must not fool yourself - and you are the easiest person to fool" — Richard Feynman

Forum Rules   •   How to report a problem   •   bunsenlabs(7)

Offline

#21 2017-12-08 03:12:33

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 3,409
Website

Re: Compton System-wide configuration settings.

Head_on_a_Stick wrote:
johnraff wrote:

I think your experiences do reinforce my argument that no vsync options at all should be applied to compton, do you agree?

...er, no.

[...]

While I agree with the decision not to enable vsync with compton by default in BL

I am confused.

My proposal is that in the stock BunsenLabs desktop compton should be run without any --backend or --vsync flags at all, do you agree with that?

I think this is the best option for us because applying any given set of flags uniformly may be advantageous for one set of hardware but deleterious for another.

YES 25px_Imperial_Seal_of_Japan.png

Agree completely.

This thread is not for discussion of what should go in the BL default config files - there is already another thread for that. (Which I am just about to revisit.)
This one is for individual users to share their specific hardware details and the settings that worked best in their case, so other users with similar hardware might try them.

Last edited by johnraff (2017-12-08 03:14:43)


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#22 2017-12-09 06:54:07

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 3,409
Website

Re: Compton System-wide configuration settings.

EDIT: ^The above is what I thought this thread was for, but-rereading the OP it seems to be a request for input to help with choosing BL defaults.
Apologies to HoaS and Tknomanzr - there seems to have been some talking at cross-purposes both here and in the other thread. Anyway, I think we're agreed that no tweaks should be put in by default, leaving it up to users to optimize things.

Considering how messy and complicated and just generally PITA all this is, I was thinking just a simple list of individual peoples' hardware and what compton settings they were using might be a nice resource for someone who didn't want to go over every single combination of settings in order to find something that might work for them.

Should we start another thread for that?


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#23 2017-12-09 07:20:55

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 3,409
Website

Re: Compton System-wide configuration settings.

johnraff wrote:

your NVIDIA card has the full force composition pipeline to deal with tearing

CompositionPipeline does not seem to be available with my card & driver. The gui shows no such option as described on the Arch Wiki, and using the terminal:

john@bunsen1:~$ nvidia-settings -V all --assign CurrentMetaMode="nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }"


john@bunsen1:~$ nvidia-settings --query CurrentMetaMode

  Attribute 'CurrentMetaMode' (bunsen1:0.0): id=50, switchable=no, source=nv-control ::
  DPY-2: nvidia-auto-select @1440x900 +0+0 {ViewPortIn=1440x900,
  ViewPortOut=1440x900+0+0}

john@bunsen1:~$ nvidia-settings --query all | grep -i composition
john@bunsen1:~$ 

It's true that querying nvidia via the terminal showed no sign of composition pipelining after trying to apply it, but I have now found that it does in fact seem to improve display of that test video, without using compton's vsync: there is some flickering and stuttering but no tearing. I've set it in xorg.conf as per the Arch Wiki, and we'll see how it goes, but it seems to be an improvement. Apologies again for being too hasty.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

Board footer

Powered by FluxBB