-
Notifications
You must be signed in to change notification settings - Fork 500
vsync guide
-
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.
-
If it’s only tearing during video playback, changing the video output of your video player might help, particularly those accelerated video output (VAAPI, VDPAU, Xv, and possibly OpenGL/GLX/SDL). It’s reported that Intel’s VAAPI driver and video output solves the tearing issue some people encountered.
-
If it’s only happening with full-screen applications, compton’s
--unredir-if-possible
unredirects the screen when there’s a full-screen window. -
Keep in mind that compton has two backends: X Render and GLX (OpenGL). I will cover them later.
-
Your driver may provide some VSync options:
-
In general you should consider those options before trying compton’s, because they may work for other applications.
-
Whether they are more effective than compton’s, though, is what I do not know.
-
In some cases, enabling both compton’s VSync and your driver’s has some negative effects. For example, it could cause compton’s repaint rate to drop below your refresh rate (reported to happen on radeon), which causes some sort of sluggish appearance. With Intel driver a reported issue of 1-2 frame delay might be related to this.
-
Those options usually could be found in
xorg.conf
,drirc
(for DRI based drivers), or the configuration tool that comes with your driver (e.g.nvidia-settings
). Typically X Render related options are inxorg.conf
while GLX related ones could be anywhere. -
Sync To VBlank
/SwapBuffersWait
(or something similar) should directly enable VSync for OpenGL applications, and whether this affects X Render as well is what I do not know (most likely not). -
With some drivers (radeon),
EnablePageFlip
enables VSync on compton (GLX backend). -
There are options on certain drivers that affect VSync of some particular video output, as well, like
XV_VSYNC
in radeon.
-
-
--paint-on-overlay
may have either positive or negative effects on VSync. As most other compositors paint on the overlay window nowadays, I assume the effect is mostly positive. -
With compton’s X Render backend:
-
You may use
--vsync
to enable compton’s VSync feature. Three VSync methods are available:drm
,opengl
,opengl-oml
.drm
should work on most DRI-based drivers;opengl
works on all drivers supportingGLX_SGI_swap_control
;opengl-oml
works on those supportingGLX_OML_sync_control
. They are all waiting VSync methods, i.e. compton waits until VBlank comes to render things to your screen. (This means they are incompatible with--sw-opti
, and they could increase compton’s performance.)compton --vsync opengl
-
Many driver-level options do not affect X Render.
-
Typically VSync under X Render backend performs worse than under GLX backend.
-
--dbe
is supposed to help, but in reality it probably doesn’t work too well.
-
-
With compton’s GLX backend:
-
Most driver-level OpenGL options affect this backend only, including those VSync ones. So when you switch to this backend you may find compton automagically VSync-ed.
-
--vsync drm/opengl/opengl-oml
works with GLX backend as well, and they sometimes work better with GLX backend. -
You get two extra VSync methods with this backend:
--vsync opengl-swc/opengl-mswc
. They are buffer-swap VSync methods, thus doesn’t throttle compton’s repaint rate (usually), and they could work with--sw-opti
. Many reported they work better than--vsync drm/opengl/opengl-oml
. -
--glx-use-copysubbuffermesa
may have negative effects on VSync.
-
-
VBlank is a very short period of time, so when your CPU or GPU is under heavy stress, compton may miss VBlank, results in tearing or frame dropping.
-
Multiple monitors or Xinerama may have negative effects over VSync, especially if they have inconsistent refresh rates, in which case at least most OpenGL VSync methods could only sync to one monitor.
-
@jeroenost 's suggestions:
Further testing today has showed me that I get best, almost perfect results by:
-
Disabling kernel preemption (
CONFIG_PREEMPT
) (keepingCONFIG_PREEMPT_VOLUNTARY=y
). I haven’t tried changing the latter to N as well. -
compton --vsync drm --paint-on-overlay
. paint-on-overlay is eliminating the sporadic tearing I saw around 50-100px from the top. Now it seems only <10px from the top and very very seldom (fast moving action scenes where the camera swipes left/right)
-
-
It’s reported that with newer nvidia-drivers, putting the following line under the
Section "Screen"
ofxorg.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.
(Source, discovered by @bucaneer in #227)