You are not logged in.
Pages: 1
Hello there,
I am having an issue with Picom using i3 window manager - it behaves very weirdly. But let's start with basic information:
DE - none, just i3wm
- i have picom experimanetal backends version
Running updated arch installation.
ISSUE:
Picom usually does not fade out (the little animation) when closing the window, it behaves the same way as if the fading was not set at all. However, during opening the window / switching between wors-kpaces, it fades out perfectly.
Also when I have multiple windows opened on the same work-space, picom fades out when one of the window is closed, but when only one is opened, no fading happens. Here is an example:
I have 3 terminal windows opened on a single work-space next to each other. When I close the 1st, fading happens, when I close the 2nd, fading happens, as well, however, during closing the 3rd one (last one), no fading happens.
Here is the whole picom configuration: https://github.com/samokosik/setup/blob … icomconfig
Important part:
#################################
# Fading #
#################################
# Fade windows in/out when opening/closing and when opacity changes,
# unless no-fading-openclose is used.
# fading = false
fading = true;
# Opacity change between steps while fading in. (0.01 - 1.0, defaults to 0.028)
# fade-in-step = 0.028
fade-in-step = 0.028;
# Opacity change between steps while fading out. (0.01 - 1.0, defaults to 0.03)
# fade-out-step = 0.03
fade-out-step = 0.03;
# The time between steps in fade step, in milliseconds. (> 0, defaults to 10)
fade-delta = 6
# Specify a list of conditions of windows that should not be faded.
# fade-exclude = []
# Do not fade on window open/close.
# no-fading-openclose = false
# Do not fade destroyed ARGB windows with WM frame. Workaround of bugs in Openbox, Fluxbox, etc.
# no-fading-destroyed-argb = falseAnyone has any idea how to solve this problem?
Thank you
"Why join the navy if you can be a pirate?"
- Steve Jobs
Offline
You've changed the default back end from xrender to glx? Does this issue exist with a different back end?
# Specify the backend to use: `xrender`, `glx`, or `xr_glx_hybrid`.
# `xrender` is the default one.
#
# backend = "xrender"
backend = "glx";
"the wind-blown way, wanna win? don't play"
Offline
Maybe more important:
blur-method ="dual_kawase"Online
Maybe more important:
blur-method ="dual_kawase"
Can I ask if this setting will affect the blur?
"Why join the navy if you can be a pirate?"
- Steve Jobs
Offline
It's the setting you have right now and I suspect it to be the cause and dual_kawase is the (in picom experimental) very wide blur effect.
Disable that (maybe all blur) and see whether it impacts your problem.
Online
It's the setting you have right now and I suspect it to be the cause and dual_kawase is the (in picom experimental) very wide blur effect.
Disable that (maybe all blur) and see whether it impacts your problem.
Disabling this option does not change how the window closes. It only removes the blur effects.
"Why join the navy if you can be a pirate?"
- Steve Jobs
Offline
And what about the xrender backend?
Online
And what about the xrender backend?
Nope, it has the same effect as turing off the blur.
"Why join the navy if you can be a pirate?"
- Steve Jobs
Offline
Probably something i3wm does.
How does fading behave w/ xcompmgr?
Online
Probably something i3wm does.
How does fading behave w/ xcompmgr?
Fading out here works (surpirsingly).
"Why join the navy if you can be a pirate?"
- Steve Jobs
Offline
To re-cap your OP, the only situation that is affected is if you close the last window on a workspace?
Does it matter whether that window is floating?
Online
To re-cap your OP, the only situation that is affected is if you close the last window on a workspace?
Does it matter whether that window is floating?
Going to sleep rn, will respond asap (:
"Why join the navy if you can be a pirate?"
- Steve Jobs
Offline
To re-cap your OP, the only situation that is affected is if you close the last window on a workspace?
Does it matter whether that window is floating?
The problem is very weird.
SCENARIO:
I have opened 3 windows next to each other, and when I was opening them, fading happened. Then I decided to close them. When closing the 1st one, fading happens, when closing the 2nd one, fading happens as well. Now I have last window opened - I close that one and no fading happens.
SCENARIO #2:
I have opened a single window (let's say urxvt). When I try to close that one urxvt window, no fading happens. (there is only 1 window opened)
Basically no fading happens when closing the last window even though it is set.
"Why join the navy if you can be a pirate?"
- Steve Jobs
Offline
Basically no fading happens when closing the last window even though it is set.
Yes, that's what I understood.
But:
Does it matter whether that window is floating?
Online
Basically no fading happens when closing the last window even though it is set.
Yes, that's what I understood.
But:seth wrote:Does it matter whether that window is floating?
oh sorry, no, the behaviour is the same even when the window is floating
"Why join the navy if you can be a pirate?"
- Steve Jobs
Offline
There's certainly a bug and the behavior is even less determinable when it comes to other WMs.
Closing windows using xdotool windoclose/kill/unmap doesn't get me a fade effect, nor does the fancy close button or typing exit/ctrl+d into a terminal, but closing it using alt+f4 is correctly handled by picom.
Here's the most weird part:
sleep 4; xdotool getactivewindow windowclose # no fade
sleep; xdotool getactivewindow windowclose # no fade
sleep4; xdotool getactivewindow windowclose # zsh asks me to fix the command to "sleep" … and the window fades outOnline
There's certainly a bug and the behavior is even less determinable when it comes to other WMs.
Closing windows using xdotool windoclose/kill/unmap doesn't get me a fade effect, nor does the fancy close button or typing exit/ctrl+d into a terminal, but closing it using alt+f4 is correctly handled by picom.Here's the most weird part:
sleep 4; xdotool getactivewindow windowclose # no fade sleep; xdotool getactivewindow windowclose # no fade sleep4; xdotool getactivewindow windowclose # zsh asks me to fix the command to "sleep" … and the window fades out
Thank you for explaining.
Can I also ask how did you manage to close a window using alt+f4?
I have alt set as my mod key and its combination with alt does not work and it does not close the window...
"Why join the navy if you can be a pirate?"
- Steve Jobs
Offline
"other WM" - in this case fluxbox. And because I've configured the shortcut to close the active window ;-)
There's already an open picom bug that looks like it's yours, right?
Online
"other WM" - in this case fluxbox. And because I've configured the shortcut to close the active window ;-)
There's already an open picom bug that looks like it's yours, right?
Yes, that opened picom bug on their github was submitted by me. (:
"Why join the navy if you can be a pirate?"
- Steve Jobs
Offline
Any updates on this? Experiencing the exact same issue.
Offline
Unless you're "rojnwa", see https://github.com/yshui/picom/issues/584
Edit:
Bug seems to have moved, 584 is 404
https://github.com/yshui/picom/issues/704
Last edited by seth (2022-08-30 19:41:54)
Online
Pages: 1