Picom: After update, "focused" is reversed

Created on 18 Nov 2019  路  18Comments  路  Source: yshui/picom

Platform

Arch

Intel graphics, no GPU, Lenovo T460S

Environment

i3-gaps
Oh-my-zsh
Termite

picom version

vgit-9a88d

Configuration:

backend = "glx";
glx-no-stencil = true;
glx-no-rebind-pixmap = 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.
glx-copy-from-front = false;

# Enabled client-side shadows on windows.
shadow = true;
# The blur radius for shadows. (default 12)
shadow-radius = 5;
# The left offset for shadows. (default -15)
shadow-offset-x = -5;
# The top offset for shadows. (default -15)
shadow-offset-y = -5;
# The translucency for shadows. (default .75)
shadow-opacity = 0.5;

# shadow-red = 0.0;
# shadow-green = 0.0;
# shadow-blue = 0.0;

# Avoid drawing shadow on all shaped windows (see also: --detect-rounded-corners)
shadow-ignore-shaped = false;

inactive-opacity = 1;
active-opacity = 1;
frame-opacity = 1;
inactive-opacity-override = false;

# Dim inactive windows. (0.0 - 1.0)
# inactive-dim = 0.2;
# Do not let dimness adjust based on window opacity.
# inactive-dim-fixed = true;
# Blur background of transparent windows. Bad performance with X Render backend. GLX backend is preferred.
# blur-background = true;
# Blur background of opaque windows with transparent frames as well.
# blur-background-frame = true;
# Do not let blur radius adjust based on window opacity.
blur-background-fixed = false;
blur-background-exclude = [
    "window_type = 'dock'",
    "window_type = 'desktop'"
];

# Fade windows during opacity changes.
fading = true;
# The time between steps in a fade in milliseconds. (default 10).
fade-delta = 10;
# Opacity change between steps while fading in. (default 0.028).
fade-in-step = 0.028;
# Opacity change between steps while fading out. (default 0.03).
fade-out-step = 0.03;
# Fade windows in/out when opening/closing
# no-fading-openclose = true;

# Specify a list of conditions of windows that should not be faded.
fade-exclude = [ ];

# Try to detect WM windows and mark them as active.
mark-wmwin-focused = true;
# Mark all non-WM but override-redirect windows active (e.g. menus).
mark-ovredir-focused = true;
# Use EWMH _NET_WM_ACTIVE_WINDOW to determine which window is focused instead of using FocusIn/Out events.
# Usually more reliable but depends on a EWMH-compliant WM.
use-ewmh-active-win = true;
# Detect rounded corners and treat them as rectangular when --shadow-ignore-shaped is on.
detect-rounded-corners = true;

# Detect _NET_WM_OPACITY on client windows, useful for window managers not passing _NET_WM_OPACITY of client windows to frame windows.
# This prevents opacity being ignored for some apps.
# For example without this enabled my xfce4-notifyd is 100% opacity no matter what.
detect-client-opacity = true;

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

# Vertical synchronization: match the refresh rate of the monitor
vsync = true;

# Enable DBE painting mode, intended to use with VSync to (hopefully) eliminate tearing.
# Reported to have no effect, though.
dbe = false;

# 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 = true;

# 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.
unredir-if-possible = false;

# Specify a list of conditions of windows that should always be considered focused.
focus-exclude = [ ];

# Use WM_TRANSIENT_FOR to group windows, and consider windows in the same group focused at the same time.
detect-transient = false;
# Use WM_CLIENT_LEADER to group windows, and consider windows in the same group focused at the same time.
# WM_TRANSIENT_FOR has higher priority if --detect-transient is enabled, too.
detect-client-leader = false;

#################################
#
# Window type settings
#
#################################

wintypes:
{
    tooltip =
    {
        # fade: Fade the particular type of windows.
        fade = true;
        # shadow: Give those windows shadow
        shadow = false;
        # opacity: Default opacity for the type of windows.
        # opacity = 0.85;
        # focus: Whether to always consider windows of this type focused.
        # focus = true;
    };
};

# Personal config
#
# Opacity on terminal focused / unfocused

opacity-rule = [
  "95:class_g = 'Termite' && !focused",
  "80:class_g = 'Termite' && focused",
  "85:class_g = 'Dunst'"
];
######################
#
# XSync
# See: https://github.com/yshui/compton/commit/b18d46bcbdc35a3b5620d817dd46fbc76485c20d
#
######################

# Use X Sync fence to sync clients' draw calls. Needed on nvidia-drivers with GLX backend for some users.
xrender-sync-fence = true;

Steps of reproduction

In my previous config I had the following :

opacity-rule = [
  "95:class_g = 'Termite' && focused", # High opacity on focused window
  "80:class_g = 'Termite' && !focused",  # Low opacity on unfocused windows
  "85:class_g = 'Dunst'"
];

I updated from Compton to Picom with pacman -Syu

Before update, config was working as intended.
After update, the opposite happened (low opacity only on focused window, high opacity on unfocused windows)

The problem was "solved" by interchanging "focused" and "!focused"

Other details

I'm quite new to picom, so I might have missed something obvious.

Most helpful comment

Sorry to hijack this issue, but I think I've found the underlying problem:
The changes of https://github.com/yshui/picom/commit/79fc36b3e30989fd638aa0531588e02b564a906c in response to https://github.com/yshui/picom/issues/134 seem to have caused this.
The parent commit works as intended. This is the first commit where I can reproduce the issue.

win_calc_opacity_target() is only called from win_update_focused() which in turn is called in win_on_focus_change().

The target opacity however, is updated in win_update_opacity_rule() called by win_on_factor_change() which in turn is called in win_on_focus_change() as well.

https://github.com/yshui/picom/blob/b0267080268b37cd3f0c0ce37fa0984fd1dbce54/src/win.c#L1467-L1476
Since the call to win_on_factor_change() is AFTER win_update_focused(), the updated opacity rules are only evaluated (in win_update_opacity_rule()) AFTER the target opacity has been set (in win_calc_opacity_target()).

Opacity must be recalculated after the conditions change. But I'm not sure where this should be implemented, as the current logic does something related to fading. As a workaround I've added

    // Always refresh opacity rules before opacity calculation as it might depend on
    // the focused state
    if (ps->o.opacity_rules)
        win_update_opacity_rule(ps, w);

before https://github.com/yshui/picom/blob/b0267080268b37cd3f0c0ce37fa0984fd1dbce54/src/win.c#L116-L127 and this restores the intended behaviour.

All 18 comments

@Samuelfaure what is the compton version you updated from?

I am experiencing the same issue and i'd like to add that at the start it's not inverted.

I updated from compton 7.4-1.

@yshui I'm not sure how to get this information*; but it was probably the latest version available on pacman. I upgrade my packages at least once a week.

*I wasnt able to find the compton package on the AUR since it got apparently deleted/replaced with picom

If that is the case then this is really unexpected, since the compton -> picom update in Arch Linux should just be a simple rename?

Is my understanding incorrect, @xyproto?

@yshui I finally managed to check the version and it was 7.4-1 too, so your understanding was correct indeed

Another weird bug that appeared at the same time :
If you pkill picom && picom -b the windows that were already opened have no opacity at all.
To make the opacity appear on a window I need to focus and then unfocus it.

EDIT : Solved this particular issue like this :

opacity-rule = [
  "90:class_g = 'Termite' && _NET_WM_STATE@:32a",
  "78:class_g = 'Termite' && !_NET_WM_STATE@:32a",
  "85:class_g = 'Dunst'"
];

Another bug : the third line about 'Dunst' is not working either... Seems to be the same issue responsible for all those problems.

I had the same issue with focus opacity in version 7.4-1.

@yshui the rename involved creating a new package named picom which also provides, replaces and conflicts with "compton". The package is still at version 7.4, but using commit 9a88d971d59ed8c33f9d8734cd0039d9fd6030a5, in lack of a release tag after the rename. Apologies if I renamed the Arch Linux package too soon, I thought it was ready, ref #222.

@xyproto The rename is totally fine. But I would prefer if you don't package an unreleased branch, since it probably is not stable enough to be used by the general public.

I think the best thing I can do here is to back port the rename to the stable/7 branch, make a 7.5 release, and you could package that. Does that sound good?

@yshui I started packaging stable/7 as a 7.5 release of the picom package, but then I noticed that the files are still called compton* on that branch. There is no official compton package anymore on Arch, just picom. Do you have a branch or tag, where the project has been renamed to picom, that I could/should rather use?

@xyproto I am in the process of back porting it. After I am done, I will tag v7.5.

@xyproto I have tagged v7.5

@yshui I gave the v7.5 a quick spin, everything looks fine to me. Updated the Arch package.

The v7.5 fixed the focus issue. Thank you.

@Azkellas Great. :+1:

@yshui Thanks for creating the v7.5 branch. :+1:

Sorry to hijack this issue, but I think I've found the underlying problem:
The changes of https://github.com/yshui/picom/commit/79fc36b3e30989fd638aa0531588e02b564a906c in response to https://github.com/yshui/picom/issues/134 seem to have caused this.
The parent commit works as intended. This is the first commit where I can reproduce the issue.

win_calc_opacity_target() is only called from win_update_focused() which in turn is called in win_on_focus_change().

The target opacity however, is updated in win_update_opacity_rule() called by win_on_factor_change() which in turn is called in win_on_focus_change() as well.

https://github.com/yshui/picom/blob/b0267080268b37cd3f0c0ce37fa0984fd1dbce54/src/win.c#L1467-L1476
Since the call to win_on_factor_change() is AFTER win_update_focused(), the updated opacity rules are only evaluated (in win_update_opacity_rule()) AFTER the target opacity has been set (in win_calc_opacity_target()).

Opacity must be recalculated after the conditions change. But I'm not sure where this should be implemented, as the current logic does something related to fading. As a workaround I've added

    // Always refresh opacity rules before opacity calculation as it might depend on
    // the focused state
    if (ps->o.opacity_rules)
        win_update_opacity_rule(ps, w);

before https://github.com/yshui/picom/blob/b0267080268b37cd3f0c0ce37fa0984fd1dbce54/src/win.c#L116-L127 and this restores the intended behaviour.

I effectively moved the opacity update logic in win_update_focused into win_on_factor_change, this should fix you problem @Samuelfaure

Closing. Reply if this is not fixed.

Was this page helpful?
0 / 5 - 0 ratings