-
-
Notifications
You must be signed in to change notification settings - Fork 585
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/Question: Fade on Destroy #704
Comments
Ok, found the solution. The solution is in picom.c itself, when a window is unmapped it will set the to_paint to false and so the fading will never happen because it isn't painted. A simple if like this: fixes this and so now fading out will animate even when closing windows. Please let me know if you wish to make a pull request on this or if at all this is something you would want to commit to the original picom. |
I'm not sure it's quite as simple as you say. I tried to merge whatever I could of that particular commit into yshui/next. I couldn't get the first part in because preprocess_paint seems to be an entirely different function. But with the rest of it, which I could get in, windows still instantly blink away when they are closed. I also tried only making the change to picom.c as suggested, but that doesn't make it work either. Here's a patch of what I tried to do:
|
Did you perhaps set |
No, it's explicitly set to false. All regular windows fade in on open, but instantly disappear on close. Menus and tooltips are the only types of windows that aren't doing that. |
Please let me know if you want to have a pull request for this and will create one just wasn't sure if you are interested in this. |
OK, this is not supposed to happen. This is a bug then. Yes, please open a PR for this, thanks! |
Just waiting on yshui/picom#704 for fades to be perfect.
bug is still here... |
Any progress on this? This issue is pretty much the last bit of jank I need to work out of my system for it to be beautiful. |
This issue is still present. I am working on updating my fork of pijulius picom to yshui's picom I have spent over 10 hours analyzing all the code side by side with meld and confirming that there are no key differences that are causing this. No obvious errors are outputted when running picom and I checked that it wasn't an issue reading the config by creating a runtime argument which manually sets the unmap animation. The line that pijulius mentioned as fixing the issue has not resolved it for me and from the looks of the recent comments it hasn't resolved it for others either. Here is the repository if either of you are interested. |
Hello Again Everyone. I have come back to let everyone know that I have resolved the issue. I believe the issue was being caused by that in With that out of the way... Picom Allusive v1.0.0 will be releasing within 10 minutes of this comment. |
hey, sorry for neglecting this. I tried several simple apps (xev, xclock, xeyes, gedit, etc.) under awesomeWM and they all fade correctly when closed. what's the app and WM combination that have this problem? |
@yshui I think that this is the cause of the issue or at least related. |
i am using endeavourOS with openbox. i tested alacritty, xev, pcmanfm, librewolf and nitrogen. theres little to no difference between these programs, only alacritty for some reason shows the animation more often. the fadeout is way more likely to happen, if theres only 1 window on the (virtual) desktop. as soon as theres 2+ windows on the desktop theyll fadeout very, very rarely. this also affects animations of closing a window on all picom forks ive tested, besides picom-allusive/compfy. so at least for my setup i can confirm that jaspers fix solved the issue 100%. i was running his fork for the last couple of months without a single occurance of the problem. if you need more information/testing from my side let me know. |
hmm, interesting. so maybe the steps underflowed, or otherwise got corrupted somewhere and became a huge number? a wild guess. |
are there any warnings from picom when closing a window? |
OK, I've found the root cause. @jasper-at-windswept it has absolutely nothing to do with openbox destroys the client window before its frame window. When the client window is destroyed, we detach it from the frame window, now the frame window has Line 978 in 197b4bd
compfy doesn't have this problem because it added an extra condition in that branch: |
Should be fixed in |
This is a follow up to 81d137a and bug #704. Basically a window will have a `XCB_NONE` as `client_win` if its previous client_win detached and then the window itself is immediately destroyed. Because the window is destroyed we couldn't call `win_recheck_client` so its `client_win` will remain `XCB_NONE`. However, it turns out we have a convention of setting `client_win` to the window itself if windows that don't have a client window. So make sure this convention is followed even for destroyed windows. Doesn't really fix anything, just to make sure an invariant holds. Related: #704 Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Ah alright. Glad you figured it out! |
Hi Guys,
I know we have the fade-out option when unmapping windows and that works perfectly fine. The questions I would have is that would it be possible to do the same when destroying windows too?
Played around a bit and was able to make it happen but unfortunately it's not 100% accurate, sometimes it does fade but most of the times it doesn't. I imagine it's because window in reality isn't there anymore but we do have the image of it, wouldn't it be possible to animate that static image in this case?
What I did for quick testing is simply replace destroy_win_start() content with unmap_win_start() and when WSTATE_UNMAPPED continue with the destroy.
What do you think guys? would this be possible at all or is the reason for not working 100% because X simply clears the window and there isn't anything we can do about it because we can't just animate a picture on the server without having the window?
Thank you in advance!
The text was updated successfully, but these errors were encountered: