perf guide

Richard Grenville edited this page Jun 1, 2014 · 4 revisions

Performance Guide

1. How to improve compton’s performance

  • If it’s only full-screen applications that have performance issues with compton running, --unredir-if-possible causes 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-opti and --vsync drm/opengl/opengl-oml both could limit compton’s repainting rate to your refresh rate (or to an arbitrary rate, with --refresh-rate and --sw-opti). Note --sw-opti and --vsync drm/opengl/opengl-oml are incompatible and using them together may cause frame dropping. --vsync opengl-swc/opengl-mswc doesn’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 in xorg.conf while 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-overlay may 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-stencil usually 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-copysubbuffermesa is 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-method has an effect very similar with --glx-use-copysubbuffermesa, so they shouldn’t be enabled together. There are 3 possible values, undefined, exchange, and copy. copy is the fastest, but it doesn’t work with most drivers (in particular, it won’t work with "Allow Flipping" on in your driver configuration). exchange is slightly slower, but works if the driver is indeed using exchange buffer swap with 2 buffers only. undefined is the slowest one, and the default value.

    • --glx-copy-from-front is similar in effect with --glx-use-copysubbuffermesa and --glx-swap-method, so only one of the three should be used. It generally performs much worse than --glx-use-copysubbuffermesa and --glx-swap-method.

    • --glx-no-rebind-pixmap should 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-fence to 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 -O2 has been tested. You are on your own if you use -O3 or 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-driver users, note you may need to run nvidia-settings --load-config-only to load its settings after X starts.

  • nvidia-drivers-337.19 seemingly causes lagging on certain cards.

  • It could be a problem related to applications:

    • With older versions of nvidia-drivers a X Render compositor becomes unusable if an application is doing video playback with VDPAU.

    • With nvidia-drivers you 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.

2. How to measure compton’s performance

2.1. GLX backend

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 0xc000f9

Where 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

--glx-no-stencil --glx-no-rebind-pixmap

nVidia GTX 670

nvidia-drivers-319.12

8

20%

6700

--glx-no-stencil --glx-no-rebind-pixmap --glx-swap-method exchange

Note all throttling options, including VSync options in the driver and in compton, as well as --sw-opti, must be turned off when benchmarking.

2.2. XRender backend

--benchmark in XRender backend seems inaccurate. I don’t know a way to measure performance in X Render backend.

3. Last but not least

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.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.