Cpp-Picom vNext: A lightweight compositor for X11

icon
Latest Release: vNext

Release timeline

rc1: TBD Final release: TBD

Changelog

@tryone144 has officially joined as a collaborator, hooray! :tada:

New features

  • New blur method for the experimental backends: dual-kawase #382
  • Support for rounding the corners of windows (no experimental backends support yet) #551 #558 #614

New options

  • New wintype option: blur-background. Now you can set the blur-background option per window type.
  • Added the shadow-color option, which is can be used to set the color of the shadow in a single option, instead setting red/green/blue separately in 3 options.

Removed options

  • no-dock-shadow and no-dnd-shadow, deprecated since v4

Improvements

  • Improve usability of the picom-trans script

Bug fixes

Source code(tar.gz)
Source code(zip)

picom

This is a development branch, bugs to be expected

This is forked from the original Compton because it seems to have become unmaintained.

The current battle plan of this fork is to refactor it to make the code possible to maintain, so potential contributors won't be scared away when they take a look at the code.

We also try to fix bugs.

You can leave your feedbacks or thoughts in the discussion tab.

The original README can be found here

Call for testers

--experimental-backends

This flag enables the refactored/partially rewritten backends.

Currently, new backends feature better vsync with the xrender backend and improved input lag with the glx backend (for non-NVIDIA users). The performance should be on par with the old backends.

New backend features will only be implemented on the new backends from now on, and the old backends will eventually be phased out after the new backends stabilize.

To test the new backends, add the --experimental-backends flag to the command you use to run picom. This flag is not available from the configuration file.

To report issues with the new backends, please state explicitly you are using the new backends in your report.

Rename

Rationale

Since the inception of this fork, the existence of two compton repositories has caused some number of confusions. Mainly, people will report issues of this fork to the original compton, or report issues of the original compton here. Later, when distros started packaging this fork of compton, some wanted to differentiate the newer compton from the older version. They found themselves having no choice but to invent a name for this fork. This is less than ideal since this has the potential to cause more confusions among users.

Therefore, we decided to move this fork to a new name. Personally, I consider this more than justified since this version of compton has gone through significant changes since it was forked.

The name

The criteria for a good name were

  1. Being short, so it's easy to remember.
  2. Pronounceability, again, helps memorability
  3. Searchability, so when people search the name, it's easy for them to find this repository.

Of course, choosing a name is never easy, and there is no apparent way to objectively evaluate the names. Yet, we have to solve the aforementioned problems as soon as possible.

In the end, we picked picom (a portmanteau of pico and composite) as our new name. This name might not be perfect, but is what we will move forward with unless there's a compelling reason not to.

Migration

Following the deprecation process, migration to the new name will be broken into 3 steps:

  1. All mentions of compton will be updated to picom in the code base. compton will still be installed, but only as a symlink to picom. When picom is launched via the symlink, a warning message is printed, alerting the user to migrate. Similarly, the old configuration file names and dbus interface names will still be accepted but warned.
  2. 3 major releases after step 1, the warning messages will be prompted to error messages and picom will not start when launched via the symlink.
  3. 3 major releases after step 2, the symlink will be removed.

The dbus interface and service names are unchanged, so no migration needed for that.

Change Log

See Releases

Build

Dependencies

Assuming you already have all the usual building tools installed (e.g. gcc, python, meson, ninja, etc.), you still need:

  • libx11
  • libx11-xcb
  • libXext
  • xproto
  • xcb
  • xcb-damage
  • xcb-xfixes
  • xcb-shape
  • xcb-renderutil
  • xcb-render
  • xcb-randr
  • xcb-composite
  • xcb-image
  • xcb-present
  • xcb-xinerama
  • xcb-glx
  • pixman
  • libdbus (optional, disable with the -Ddbus=false meson configure flag)
  • libconfig (optional, disable with the -Dconfig_file=false meson configure flag)
  • libGL (optional, disable with the -Dopengl=false meson configure flag)
  • libpcre (optional, disable with the -Dregex=false meson configure flag)
  • libev
  • uthash

On Debian based distributions (e.g. Ubuntu), the list of needed packages are

libxext-dev libxcb1-dev libxcb-damage0-dev libxcb-xfixes0-dev libxcb-shape0-dev libxcb-render-util0-dev libxcb-render0-dev libxcb-randr0-dev libxcb-composite0-dev libxcb-image0-dev libxcb-present-dev libxcb-xinerama0-dev libxcb-glx0-dev libpixman-1-dev libdbus-1-dev libconfig-dev libgl1-mesa-dev libpcre2-dev libpcre3-dev libevdev-dev uthash-dev libev-dev libx11-xcb-dev

To build the documents, you need asciidoc

To build

$ git submodule update --init --recursive
$ meson --buildtype=release . build
$ ninja -C build

Built binary can be found in build/src

If you have libraries and/or headers installed at non-default location (e.g. under /usr/local/), you might need to tell meson about them, since meson doesn't look for dependencies there by default.

You can do that by setting the CPPFLAGS and LDFLAGS environment variables when running meson. Like this:

$ LDFLAGS="-L/path/to/libraries" CPPFLAGS="-I/path/to/headers" meson --buildtype=release . build

As an example, on FreeBSD, you might have to run meson with:

$ LDFLAGS="-L/usr/local/lib" CPPFLAGS="-I/usr/local/include" meson --buildtype=release . build
$ ninja -C build

To install

$ ninja -C build install

Default install prefix is /usr/local, you can change it with meson configure -Dprefix=<path> build

How to Contribute

Code

You can look at the Projects page, and see if there is anything that interests you. Or you can take a look at the Issues.

Non-code

Even if you don't want to contribute code, you can still contribute by compiling and running this branch, and report any issue you can find.

Contributions to the documents and wiki will also be appreciated.

Contributors

See CONTRIBUTORS

Comments

  • add uninstallation instructions
    add uninstallation instructions

    Dec 26, 2021

    Add instructions for uninstallation in readme.

    Reply
  • Picom makes text transparent?
    Picom makes text transparent?

    Jan 1, 2022

    Platform

    Ubuntu Desktop 21.04 64-bit

    GPU, drivers, and screen setup

    NVIDIA GeForce RTX 3070, GeForce Game Ready Driver Version 465.89 (on host)

    name of display: :0 display: :0 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Mesa/X.org (0xffffffff) Device: llvmpipe (LLVM 12.0.0, 256 bits) (0xffffffff) Version: 21.0.3 Accelerated: no Video memory: 9956MB Unified memory: no Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 3.1 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 OpenGL vendor string: Mesa/X.org OpenGL renderer string: llvmpipe (LLVM 12.0.0, 256 bits) OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.0.3 OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile

    OpenGL version string: 3.1 Mesa 21.0.3 OpenGL shading language version string: 1.40 OpenGL context flags: (none)

    OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.0.3 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

    Environment

    Oracle VM VirtualBox awesome wm

    picom version

    vgit-a8445

    Diagnostics

    Version: vgit-a8445

    Extensions:

    • Shape: Yes
    • XRandR: Yes
    • Present: Present

    Misc:

    • Use Overlay: No (Another compositor is already running)
    • Config file used: $HOME/.config/picom/picom.conf

    Drivers (inaccurate):

    Configuration:

    Configuration file
    active-opacity = 1;
    inactive-opacity = 1;
    
    opacity-rule = [
        "10:class_g = 'Alacritty'",
        "50:class_g = 'Emacs'",
        "100:class_g = 'Firefox'"
    ];
    

    Steps of reproduction

    1. Run picom & with the above configuration file.

    Expected behavior

    Only the background of the application (alacritty, emacs, etc.) is made transparent, not the text.

    Current Behavior

    Both the background and text are made transparent.

    Stack trace

    Other details

    Reply
  • blurred/transparent frame includes window client area and flickers (experimental backends)
    blurred/transparent frame includes window client area and flickers (experimental backends)

    Jan 10, 2022

    Platform

    Gentoo

    GPU, drivers, and screen setup

    NVIDIA GTX 1050, nvidia-drivers 495.46-r10

    name of display: :0
    display: :0  screen: 0
    direct rendering: Yes
    Memory info (GL_NVX_gpu_memory_info):
        Dedicated video memory: 2048 MB
        Total available memory: 2048 MB
        Currently available dedicated video memory: 1711 MB
    OpenGL vendor string: NVIDIA Corporation
    OpenGL renderer string: NVIDIA GeForce GTX 1050/PCIe/SSE2
    OpenGL core profile version string: 4.6.0 NVIDIA 495.46
    OpenGL core profile shading language version string: 4.60 NVIDIA
    OpenGL core profile context flags: (none)
    OpenGL core profile profile mask: core profile
    
    OpenGL version string: 4.6.0 NVIDIA 495.46
    OpenGL shading language version string: 4.60 NVIDIA
    OpenGL context flags: (none)
    OpenGL profile mask: (none)
    
    OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 495.46
    OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
    

    Environment

    openbox

    picom version

    vgit-31e58 (experimental backends)

    Diagnostics
    **Version:** vgit-31e58
    
    ### Extensions:
    
    * Shape: Yes
    * XRandR: Yes
    * Present: Present
    
    ### Misc:
    
    * Use Overlay: No
      (Another compositor is already running)
    * Config file used: /home/mike/.config/picom.con
    
    ### Drivers (inaccurate):
    
    NVIDIA
    
    ### Backend: glx
    
    * Driver vendors:
     * GLX: NVIDIA Corporation
     * GL: NVIDIA Corporation
    * GL renderer: NVIDIA GeForce GTX 1050/PCIe/SSE2
    
    

    Configuration:

    Configuration file
    backend = "glx";
    glx-no-stencil = true;
    glx-no-rebind-pixmap = true;
    glx-copy-from-front = false;
    use-damage = true;
    refresh-rate = 60;
    vsync = true;
    xrender-sync-fence = false;
    
    mark-wmwin-focused = true;
    mark-ovredir-focused = true;
    use-ewmh-active-win = true;
    unredir-if-possible = true;
    
    detect-client-opacity = false;
    detect-transient = true;
    detect-client-leader = true;
    inactive-opacity-override = false;
    frame-opacity=0.6;
    blur-background = true;
    blur-background-frame = true;
    blur-background-fixed = true;
    blur:
    {
            method = "dual_kawase";
            strength = 3;
    }
    
    ... rest is omitted for brevity
    

    Steps of reproduction

    Specifc reproduction steps may be difficult as it isn't always consistent. However, it seems that it is somehow affected by which workspaces the windows are on, and that all windows on only some workspaces (at seemingly random times) suffer from the effect

    Expected behavior

    Blurred+transparent frames should only contain what is actually behind the window (window client area is part of the window, not behind it)

    Current Behavior

    The window frame seems to sometimes render "above" the client area and hence causes a strange "bleeding" effect. This is accompanied by a "flicker" on window updates

    Other details

    see example video; I've exaggerated the size and transparency of the frame to make the effect more obvious

    https://user-images.githubusercontent.com/42143005/148721156-0fc68357-5b9c-42b3-b673-8f40028f0434.mp4

    Thanks! (also for this great piece of software)

    Reply
  • Picom appears to be unmaintained
    Picom appears to be unmaintained

    Jan 10, 2022

    Is picom still maintained?

    Reply
  • Fix all misspellings of _NET_WM_WINDOW_OPACITY.
    Fix all misspellings of _NET_WM_WINDOW_OPACITY.

    Jan 12, 2022

    null

                                                                                                                                                                                                           
    Reply
  • Fix 2 examples in manpage which had obsolete options.
    Fix 2 examples in manpage which had obsolete options.

    Jan 12, 2022

    null

                                                                                                                                                                                                           
    Reply
  • Screen Tearing with M&B Warband
    Screen Tearing with M&B Warband

    Jan 28, 2019

    Platform

    Gentoo

    GPU, drivers, and screen setup

    Radeon 535 mobile,vega3 llvm 7.0.1 mesa 18.3.2

    Environment

    xfce4 4.12.5

    Compton version

    Next and Master

    Compton configuration:

    shadow = true;
    no-dnd-shadow = true;
    no-dock-shadow = true;
    clear-shadow = true;
    shadow-radius = 7;
    shadow-offset-x = -7;
    shadow-offset-y = -7;
    shadow-opacity = 0.5;
    
    shadow-exclude = [
    	"name = 'Notification'",
    	"class_g = 'VirtualBox'",
    	"class_g = 'Chromium'",
    	"class_g = 'Conky'",
    	"class_g ?= 'Notify-osd'",
    	"class_g = 'Cairo-clock'",
    	"! name~=''",
    	"[email protected]:c"
    ];
    
    # Opacity
    menu-opacity = 0.87;
    inactive-opacity = 1.0;
    frame-opacity = 0.95;
    inactive-opacity-override = false;
    alpha-step = 0.06;
    
    opacity-rule = [ "80:class_g = 'XTerm'" ];
    
    # Other
    backend = "glx";
    mark-wmwin-focused = true;
    mark-ovredir-focused = true;
    detect-rounded-corners = true;
    detect-client-opacity = true;
    refresh-rate = 60;
    sw-opti = false;
    unredir-if-possible = true;
    unredir-if-possible-exclude = [ "class_g = 'smplayer'",
    "class_g = 'firefox'" ];
    focus-exclude = [ "class_g = 'Cairo-clock'" ];
    detect-transient = true;
    detect-client-leader = true;
    invert-color-include = [ ];
    
    # GLX backend
    vsync = "opengl-mswc";
    paint-on-overlay = true;
    vsync-use-glfinish= true;
    glx-no-stencil = true;
    glx-copy-from-front = false;
    glx-no-rebind-pixmap = true;
    glx-swap-method = "buffer-age";
    glx-use-gpushader4 = true;
    wintypes:
    {
      tooltip = { fade = true; shadow = true; opacity = true; focus = true; };
    };
    

    Steps of reproduction

    start mount and blade warband with radeon 535 play a map there is always screen tearing at the top of screen, regardless of in-game vsync on/off

    Expected behavior

    No screen tearing with in-game vsync on

    Current Behavior

    Screen tearing with in-game vsync on

    Other details

    All other games work fine with compton-next/master and in-game vsync on, mount and blade warband works without screen tearing with the old compton and my current config.If i use vega 3 gpu with compton-next/master no screen tearing, it happens only with mount and blade+radeon 535+compton-next/master.

    backend: glx info requested driver: amdgpu 
    Reply
  • Dim bright windows
    Dim bright windows

    Sep 30, 2019

    Hey,

    I have no idea if anybody is interested in this, so if You think it is useless for general case, just close this PR :wink:.

    Anyway, I had this annoying problem, that when frequently switching between dark-themed windows and light-themed ones (especially when they take up most of the screen) there is no good screen brightness for both of them. Either dark-themed ones are too dark to comfortably look at them or light ones are too bright.

    So I implemented this feature hoping to reduce that gap a bit by dimming windows depending on how bright they are.

    Now initially I tried to implement this using mipmaps for brightness estimation, but there was significant CPU overhead on my computer (intel integrated GPU from 3rd gen processor, I also tested on 8th gen). What is more in order for them to work as expected, textures had to be scaled/padded in some way to power of two, this was somewhat inconvenient. So then I just decided to sample some pixels from texture in vertex shader, get an estimate on brightness, and pass it to fragment shader which can do the dimming. This, at least on my tests, did not incur any significant CPU or GPU load (during testing I used sample size of 40 for each dimension, so in total 1600 samples).

    I also experimented a bit with different ways of estimating lightness, but I did not notice big differences on real windows, so I just left average for simplicity.

    This works only on newer glx backend.

    Reply
  • picom: ../src/win.c:704: win_set_shadow: Assertion `w->flags & WIN_FLAGS_IMAGES_NONE' failed.
    picom: ../src/win.c:704: win_set_shadow: Assertion `w->flags & WIN_FLAGS_IMAGES_NONE' failed.

    Nov 23, 2019

    picom crashes immediately when I change workspace in Mate 1.23.2. xorg-x11-server-Xorg-1.20.5-7.fc30

    d4e76b271acd46b0587f739776efecf48d91553f is the first bad commit
    commit d4e76b271acd46b0587f739776efecf48d91553f
    Author: Yuxuan Shui <[email protected]>
    Date:   Mon Nov 18 22:34:05 2019 +0000
    
        win: delayed release of shadow image
        
        Previously win_set_shadow tries to release the shadow image when turning
        off shadow for a window. When shadow is turned off _immediately_ after
        it's turned on, picom won't have a chance to handle the delayed creation
        of the shadow before win_set_shadow tries to release the shadow image,
        causing a assertion failure because win_set_shadow tried to release a
        non-existing image.
        
        This commit makes releasing the shadow image delayed as well.
        
        In theory, we could check the STALE flag in win_set_shadow before
        release the image, but that duplicates the logic that is already in
        win_process_flags.
        
        Signed-off-by: Yuxuan Shui <[email protected]>
    
     src/win.c                               | 47 ++++++++++++++++++++---------
     tests/run_tests.sh                      |  1 +
     tests/testcases/issue239_3.py           |  2 ++
     tests/testcases/issue239_3_norefresh.py | 52 +++++++++++++++++++++++++++++++++
     4 files changed, 89 insertions(+), 13 deletions(-)
     create mode 100755 tests/testcases/issue239_3_norefresh.py
    

    Platform

    Fedora 30, Mate 1.23 x86_64

    GPU, drivers, and screen setup

    name of display: :0
    display: :0  screen: 0
    direct rendering: Yes
    Extended renderer info (GLX_MESA_query_renderer):
        Vendor: X.Org (0x1002)
        Device: Radeon 550 Series (POLARIS12, DRM 3.27.0, 4.19.83+, LLVM 8.0.0) (0x699f)
        Version: 19.2.4
        Accelerated: yes
        Video memory: 4096MB
        Unified memory: no
        Preferred profile: core (0x1)
        Max core profile version: 4.5
        Max compat profile version: 4.5
        Max GLES1 profile version: 1.1
        Max GLES[23] profile version: 3.2
    Memory info (GL_ATI_meminfo):
        VBO free memory - total: 1705 MB, largest block: 1705 MB
        VBO free aux. memory - total: 4052 MB, largest block: 4052 MB
        Texture free memory - total: 1705 MB, largest block: 1705 MB
        Texture free aux. memory - total: 4052 MB, largest block: 4052 MB
        Renderbuffer free memory - total: 1705 MB, largest block: 1705 MB
        Renderbuffer free aux. memory - total: 4052 MB, largest block: 4052 MB
    Memory info (GL_NVX_gpu_memory_info):
        Dedicated video memory: 4096 MB
        Total available memory: 8192 MB
        Currently available dedicated video memory: 1705 MB
    OpenGL vendor string: X.Org
    OpenGL renderer string: Radeon 550 Series (POLARIS12, DRM 3.27.0, 4.19.83+, LLVM 8.0.0)
    OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.2.4
    OpenGL core profile shading language version string: 4.50
    OpenGL core profile context flags: (none)
    OpenGL core profile profile mask: core profile
    
    OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.2.4
    OpenGL shading language version string: 4.50
    OpenGL context flags: (none)
    OpenGL profile mask: compatibility profile
    
    OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.2.4
    OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
    

    Using 3840x2160 with one display.

    picom version

    **Version:** vgit-42cd5
    
    ### Extensions:
    
    * Shape: Yes
    * XRandR: Yes
    * Present: Present
    
    ### Misc:
    
    * Use Overlay: Yes
    * Config file used: None
    
    ### Drivers (inaccurate):
    
    AMDGPU, Radeon  
    

    Configuration:

    picom --backend=glx --use-damage -c --vsync
    

    Steps of reproduction

    read above

    Reply
  • Flickering and rendering issues; non-functional (Nouveau)
    Flickering and rendering issues; non-functional (Nouveau)

    Oct 30, 2018

    Platform

    Arch Linux (4.18.16-arch1-1-ARCH)

    GPU, drivers, and screen setup

    • NVidia GTX 670,
    • xf86-video-nouveau and mesa (OpenGL)
    • Two monitors configured side-by-side with xrandr

    Environment

    • i3-wm

    Compton version

    v3-rc2-18-gc0d7f9d

    Compton configuration:

    Default

    Steps of reproduction

    1. Start compton

    Expected behaviour

    composite manager runs and provides compositing

    Current Behaviour

    Severe rendering issues; rapid flickering; window frequently disappears (see video)

    Other details

    Link to video (Google Drive - download if stream doesn't work) of behaviour: compton_issue.mp4 The program vlc is running in the active window as an example.

    backend: glx driver artifacts 
    Reply
  • Add rounded corners
    Add rounded corners

    Aug 29, 2019

    Fairly experimental. This only works with the xrender backend, and also won't work with transparent window frames.

    Also, in order to properly render the transparent parts of the corner I had to tear out all the reg_ignore stuff. There may will be a better way of doing this (like calculating a region for each window that does not include the transparent area). I will look into this.

    Fixes #214

    Edit: I have noticed that my indentation is not consistent with the rest of the codebase, I will fix this tomorrow.

    Reply
  • Poor performance when vsync is enabled
    Poor performance when vsync is enabled

    Oct 22, 2018

    Platform

    Arch Linux

    GPU, drivers, and screen setup

    Radeon RX580, amdgpu

    Environment

    i3-git

    Compton version

    Latest -git (v3-rc2-3-ga47f112 as of this writing)

    Compton configuration:

    backend = "glx"
    paint-on-overlay = true
    unredir-if-possible = true
    glx-no-stencil = true
    glx-no-rebind-pixmap = true
    glx-swap-method = "copy"
    
    opacity-rule = [
        "0:[email protected]:32a *= '_NET_WM_STATE_HIDDEN'"
    ];
    

    Testing

    The following vsync modes were tested, with GALLIUM_HUD=fps to have real numbers to compare:

    • opengl-swc/opengl-mswc: massive stutter when dragging windows even though the HUD reads 60 fps. These are enabled by default with mesa and libdrm, so the rest requires vblank_mode=0 in the environment to prevent that from interfering.
    • No vsync at all: nearly 1000 fps when dragging windows, perfectly smooth but obviously tears all over the screen.
    • opengl or drm: smooth, (almost) no tearing, slight dips when switching workspaces.
    • opengl-oml: fails to vsync.
    backend: glx performance upstream driver: amdgpu 
    Reply