-
Notifications
You must be signed in to change notification settings - Fork 500
perf guide
-
If it’s only full-screen applications that have performance issues with compton running,
--unredir-if-possiblecauses compton to unredirect the screen (thus with almost zero performance penalty) when there’s a full-screen window. -
One of the first thing you need to check is where the bottleneck is, CPU or GPU. If it’s a problem on CPU you will generally see a high CPU usage of either compton or X process. System-wide profiling could be vastly helpful in the case. Problems on GPU are a lot less visible. If your driver doesn’t provide a tool to view GPU usage (like
nvidia-smi), you probably could spot something from increased fan speed or high graphic card performance level. -
The choice of backend is one of the most important factor. At the time of writing, compton has a X Render backend, and a GLX (OpenGL) backend. Which one is faster? Well, I don’t know. Just a list of differences between them I would think of right now regarding performance:
-
X Render is probably partially hardware-accelerated or not accelerated at all, while GLX is usually hardware-accelerated.
-
X Render works on almost any environment (with possibly small glitches on unreliable drivers). GLX/OpenGL is highly dependent on the drivers. With a broken driver (like those VIA ones) there’s a chance that it can’t work at all.
-
In general GLX backend is faster than X Render and uses less CPU for sane drivers, but this is not always the case.
-
GLX backend has a number of fine-tune options and usually far more control on the driver side that may affect performance. This means GLX backend is more sensitive to driver settings, though.
-
GLX backend generally has better VSync, but that’s another story.
-
-
A method that almost always works is to throttle the repaints.
--sw-optiand--vsync drm/opengl/opengl-omlboth could limit compton’s repainting rate to your refresh rate (or to an arbitrary rate, with--refresh-rateand--sw-opti). Note--sw-optiand--vsync drm/opengl/opengl-omlare incompatible and using them together may cause frame dropping.--vsync opengl-swc/opengl-mswcdoesn’t have this effect. -
Your driver options may worth investigating:
-
In general you will find those options 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.confwhile GLX related ones could be anywhere. -
"Sync to VBlank" or something similar is typically good for performance, but it’s reported that in some cases this option actually somehow throttles compton’s painting in GLX backend to a rate lower than your refresh rate, creating artificial slowness.
-
"Allow Flipping" / "EnablePageFlip" is generally beneficial as well, yet with the option on certain optimizations (in particular,
--glx-swap-method) on GLX backend might become impossible.
-
-
--paint-on-overlaymay have either positive or negative effect on performance. Most compositors paints on the overlay windows nowadays, though. -
GLX backend optimization. GLX backend has a lot of fine-tune options that could be beneficial:
-
--glx-no-stencilusually increases performance quite significantly (around 15%). Its only problem I currently know is a theoretical risk of repainting a single area for multiple times. I have never seen this happening, however. -
--glx-use-copysubbuffermesais effective when only a small part of your screen is updated. The drawback is it generally works only with Mesa drivers, and LLVMpipe may have some issues handling it. It may or may not have a negative effect on--vsync opengl-swc/opengl-mswc. -
--glx-swap-methodhas an effect very similar with--glx-use-copysubbuffermesa, so they shouldn’t be enabled together. There are 3 possible values,undefined,exchange, andcopy.copyis the fastest, but it doesn’t work with most drivers (in particular, it won’t work with "Allow Flipping" on in your driver configuration).exchangeis slightly slower, but works if the driver is indeed using exchange buffer swap with 2 buffers only.undefinedis the slowest one, and the default value. -
--glx-copy-from-frontis similar in effect with--glx-use-copysubbuffermesaand--glx-swap-method, so only one of the three should be used. It generally performs much worse than--glx-use-copysubbuffermesaand--glx-swap-method. -
--glx-no-rebind-pixmapshould work on most drivers (except LLVMpipe), and is useful if you have a window with content rapidly changing.
-
-
Improper VSync may cause feeling of lagging. Always try disabling all VSync options in your driver and compton before determining it’s a performance problem.
-
On GLX backend, bad synchronization between X Render and GLX may lead to some sort of lagging effect (especially with
nvidia-drivers). Use--xrender-sync-fenceto deal with it. -
Compiler optimizations. Usually the bottleneck of compton is not on CPU, but it may help in some degree to tune your
CFLAGS. Compton could be optimized just like any other program, and you could refer to any a generic compilation optimization guide for more details. No optimization beyond-O2has been tested. You are on your own if you use-O3or something more aggressive. -
Certain options are known to cause significant slowdowns, like the background blur and color inversion ones. They typically run faster with GLX backend, but if that doesn’t work well enough for you, you may need to disable them. Alpha blending (semi-transparent things) is slower than fully opaque content, yet it shouldn’t be a problem in most cases.
-
For
nvidia-driverusers, note you may need to runnvidia-settings --load-config-onlyto load its settings after X starts. -
nvidia-drivers-337.19seemingly causes lagging on certain cards. -
It could be a problem in the application as well.
-
With older versions of nvidia-drivers a X Render compositor becomes unusable if an application is doing video playback with VDPAU.
-
With
nvidia-driversyou may see lagging when you drag a window above an OpenGL window. -
Other CPU/GPU intensive applications may slow compton down.
-
-
A performance problem that happens only after a long time of usage may indicate a resource leakage bug in compton.
-
Usage of multiple screens, especially with Xinerama, may have an effect on compton’s performance.
-
You should really stay away from a compositor if you use a remote X server.
Usually we measure performance of compton’s GLX backend with --benchmark, which forces compton to repeatedly repaint for specified times then exit, like:
/usr/bin/time compton --backend glx --benchmark 10000--benchmark forces full-screen repaints, but some optimizations are useful only for partial repaints. You could use --benchmark-wid for simulating partial repaints:
/usr/bin/time compton --backend glx --benchmark 10000 --benchmark-wid 0xc000f9Where 0xc000f9 is the window ID of the one of the frame (top-level) windows.
The actual result depends on a number of extra factors: The number of windows mapped, your configuration, the resolution, and the WM used, so it isn’t reliable to compare FPS across different machines. But here are some known FPS results:
| Graphic card/chip | Driver | Mapped windows | Repaint area | FPS | Options |
|---|---|---|---|---|---|
nVidia GTX 670 |
nvidia-drivers-319.12 |
8 |
100% |
4370 |
|
nVidia GTX 670 |
nvidia-drivers-319.12 |
8 |
20% |
6700 |
|
Note all throttling options, including VSync options in the driver and in compton, as well as --sw-opti, must be turned off when benchmarking.
Each and every compositor causes loss in performance, as indicated by all those benchmarks from Phoronix. The problem is only worse for a separate X compositor (instead of a compositing WM) because we have to maintain a separate X connection and such. For full-screen applications we have --unredir-if-possible, but we presently don’t have a way to disable compton on a specific normal window. As a last resort, you may kill compton when you meet the situation.