[Feature Request] Need help testing animations

[FT-Labs]

Hello guys,

I did not want to open up a pull request since it might have some way to go for it.

I've tried to implement a general animation fork, with minor code added. It is on a different branch, I will post the link below.

I would appreciate it if someone can try with different window managers, I've only tested this on pdwm only.

Thanks for everyone who wants to help.

https://github.com/FT-Labs/picom/tree/generalanimation

[Amoebawp]

Hi there,

As far as i can tell,
This branch is working flawlessly on a stock dwm - guess that was to be expected.
i3 is more laggy, seems to struggle a lot when opening/closing/resizing the master window.
awesomeWM seems to work fine, no particular issue.

The quality of the animations are pretty neat, great job on that.
Would appreciate a way to exclude some windows, can get a bit dizzy when dealing with sub-menus.

Overall this is probably the best looking animation fork of picom i ever tried. Thank you for your work.

I will spin a few more wm and report back if i ever find something off.

Edit : resizing windows seems to massively wobble the inner content and create lots of visual artifacts.

Here's the config used :

#  Animations   #

# fly-in: Windows fly in from random directions to the screen
# maximize: Windows pop from center of the screen to their respective positions
# minimize: Windows minimize from their position to the center of the screen
# slide-in-center: Windows move from upper-center of the screen to their respective positions
# slide-out-center: Windows move to the upper-center of the screen
# slide-left: Windows are created from the right-most window position and slide leftwards
# slide right: Windows are created from the left-most window position and slide rightwards
# slide-down: Windows are moved from the top of the screen and slide downward
# slide-up: Windows are moved from their position to top of the screen
# squeeze: Windows are either closed or created to/from their center y-position (similar to a blinking eye)
# squeeze-bottom: Similar to squeeze, but the animation starts from bottom-most y-position
# zoom: Windows are either created or destroyed from/to their center (not the screen center)

#enable or disable animations
animations = true;

#change animation speed of windows in current tag e.g open window in current tag
animation-stiffness-in-tag = 125;

#change animation speed of windows when tag changes
animation-stiffness-tag-change = 90.0;

animation-window-mass = 0.4;
animation-dampening = 15;
animation-clamping = true;

#open windows
animation-for-open-window = "zoom";

#minimize or close windows
animation-for-unmap-window = "squeeze";

#popup windows
animation-for-transient-window = "slide-down"; 

#set animation for windows being transitioned out while changing tags
animation-for-prev-tag = "slide-left";

#enables fading for windows being transitioned out while changing tags
enable-fading-prev-tag = true;

#set animation for windows being transitioned in while changing tags
animation-for-next-tag = "slide-right";

#enables fading for windows being transitioned in while changing tags
enable-fading-next-tag = true;

[shasherazi]

Hello. I tried it on bspwm, and it worked pretty well. It didn't differentiate between prev-tag and next-tag for me. It just applied the animation for next-tag almost all the time (except for that one time when it actually applied the prev-tag animation, but I only saw it working once).

The animation quality is fairly good. But it can give you a headache for some reason. I think it would be right to exclude popups from animation by default, as @Amoebawp said. Even the right-click popups on browsers fly across the screen for me. Also, thanks to @Amoebawp for the config. I would've struggled a lot searching for it otherwise.

[servimo]

I tried with Xfce, it worked. I used the configs for animations by @Amoebawp. Tomorrow I will give another look at options.
I didn't see animation when window close.

[Monsterovich]

@FT-Labs

I tested it, so far I can't use it because too many crashes.

1. When I close a window or maximize/focus on an already opened window, I get an assert crash.

picom: ../src/win.c:1558: win_on_win_size_change: Assertion `w->state != WSTATE_UNMAPPED && w->state != WSTATE_DESTROYING && w->state != WSTATE_UNMAPPING' failed.

or

picom: ../src/win.c:355: win_bind_mask: Assertion «!w->mask_image» failed.

2. The Xfce4 panel collapse animation is totally crazy.
3. I don't like the opening popups, because the text in them too deformed as if the rendering of a scaled framebuffer isn't enough anti-aliased (Did you apply GL_LINEAR_MIPMAP_LINEAR or something?).
4. I also have GLX error at line 706: GL_INVALID_FRAMEBUFFER_OPERATION errors in the console.

Here's a testing video (sorry for the quality, I was on my shitty laptop)

2023-04-23 02-56-30.mkv.zip

P.S.

I can also test on my NVidia GPU.

P.P.S.

I used configuration provided by @Amoebawp

[servimo]

I didn't see any crash. I use the backend "egl" and start picom with -b (daemonize).

[FT-Labs]

Hey everyone,

Appreciate your time for trying to test it. I've made a new commit, could you please try the latest one? I hope this will work now.

FT-Labs@e9834a5

@Monsterovich that is another issue I think, for fading to work on animations I needed to add unmapping statement there.
After this issue is resolved, I will fix the ability to stop animations for selected windows as well. Thanks guys!

[FT-Labs]

I hope im not thinking correctly because this will work with window managers or DE but not both

[EpsilonKu]

Hi, tried with commit e9834a5. Next-tag and prev-tag animation doesn't work(tried different configs, for example: @Amoebawp). Other animations works fine.

    OS: ArcoLinux
    Kernel: 6.2.10-zen1-1-zen
    Resolution: 1920x1080
    WM: awesome
    CPU: Intel i5-1035G1 (8) @ 3.600GHz
    GPU: Intel Iris Plus Graphics G1
    GPU: NVIDIA GeForce MX330
    GPU Driver: i915

[Amoebawp]

Tried the latest commit on dwm, i3, bspwm, leftwm and awesome.

All were working as expected really, some minor visual bugs - when opening several windows, some may glitch a bit and fail to render any animation. It's not particulary annoying.
All animations were working correctly, resizing aswell, prev/next tab also. I can't say i'm having particular issue... everything's quite smooth really

Here's a quick capture on DWM, but all where behaving like this on my end
https://youtu.be/24n2JiQIogM

If i had to mention two annoying things : visual glitch when resizing window + animations on right click/context menu (Xmenu) that would need to be excluded.

@FT-Labs do you need us to test something a bit more specific ?

Here's an updated config after some adjustments to my liking ( with Fading )

#################################
#           Animations          #
#################################

# fly-in: Windows fly in from random directions to the screen
# maximize: Windows pop from center of the screen to their respective positions
# minimize: Windows minimize from their position to the center of the screen
# slide-in-center: Windows move from upper-center of the screen to their respective positions
# slide-out-center: Windows move to the upper-center of the screen
# slide-left: Windows are created from the right-most window position and slide leftwards
# slide right: Windows are created from the left-most window position and slide rightwards
# slide-down: Windows are moved from the top of the screen and slide downward
# slide-up: Windows are moved from their position to top of the screen
# squeeze: Windows are either closed or created to/from their center y-position (similar to a blinking eye)
# squeeze-bottom: Similar to squeeze, but the animation starts from bottom-most y-position
# zoom: Windows are either created or destroyed from/to their center (not the screen center)

#################################

#enable or disable animations
animations = true;

#change animation speed of windows in current tag e.g open window in current tag
animation-stiffness-in-tag = 52;

#change animation speed of windows when tag changes
animation-stiffness-tag-change = 25.0;

animation-window-mass = 0.2;
animation-dampening = 7;
animation-clamping = true;

#open windows
animation-for-open-window = "zoom";

#minimize or close windows
animation-for-unmap-window = "zoom";

#popup windows
animation-for-transient-window = "slide-down"; 

#set animation for windows being transitioned out while changing tags
animation-for-prev-tag = "slide-left";

#enables fading for windows being transitioned out while changing tags
enable-fading-prev-tag = true;

#set animation for windows being transitioned in while changing tags
animation-for-next-tag = "slide-right";

#enables fading for windows being transitioned in while changing tags
enable-fading-next-tag = true;

#################################
#           Fading              #
#################################


# Fade windows in/out when opening/closing and when opacity changes,
#  unless no-fading-openclose is used.
fading = true

# Opacity change between steps while fading in. (0.01 - 1.0, defaults to 0.028)
fade-in-step = 0.04;

# Opacity change between steps while fading out. (0.01 - 1.0, defaults to 0.03)
fade-out-step = 0.06;

# The time between steps in fade step, in milliseconds. (> 0, defaults to 10)
fade-delta = 10

[BANanaD3V]

bspwm user here searching for fork with animations, rounded corners and blur, haha. for me, all works cool except animation-for-prev-tag, it only executes once. Thats it, everything else is flawless.

edit: actually, https://github.com/fdev31/picom works flawlessly. Only thing is i'd like workspace switch animations.

[Crylia]

Tag change animations don't work in awesome, it looks like it doesn't recognize it as a tag change? Also when minimizing a client the animation for it doesn't play at all.

[BANanaD3V]

edit: actually, https://github.com/fdev31/picom works flawlessly. Only thing is i'd like workspace switch animations.

actually, it doesnt now. strange one, prev-tag executes only once as in ft-labs. needs testing

[EpsilonKu]

@BANanaD3V It's not next-tag or prev-tag animation. It's window creation animation. It execute once because picom think that it's newly created window.

[FT-Labs]

Tag switch will be fixed soon. The other issue that is scratching my mind is properly handling xunmapwindow and xdestroywindow events.

Some simpler window managers like dwm do not use minimize or destroy windows. It only unmaps the window and free the window because there is no iconization or minimization in dwm.

After I got the fix for this issue, hopefully the last issue is going to be fixing glitches while shadows are enabled on low performance computers.

[CarDGee]

It crashes when I close a window on qtile with the following error :
"picom: ../picom-9999/src/win.c:1550: win_on_win_size_change: a asserção "w->state != WSTATE_UNMAPPED && w->state != WSTATE_DESTROYING && w->state != WSTATE_UNMAPPING" falhou"

[StitiFatah]

My 2 cents on i3 :

It works, it's usable but not optimal and still sometimes feels glitchy, it's an overall feeling, I don't know how to express it clearly but for example when refreshing my config polybar may not appear and I would need to refresh again, not a real world case but just for reference if I spam super + enter and open bunch of terminals the desktop will quickly become ultra zoomed without any possibility to take control other than going to a tty and kill picom, with main picom I feel like I could open the double amount of terminals easily without much problems.

[Aaazd]

Every animation is extremely buggy (not usable) with the following error :
GLX error at line X: GL_INVALID_VALUE
with x being a number of course.

[BowDown097]

Tested on Openbox. Visual glitches with the title bar when minimizing regardless of effect (but like 10% of the time it works fine?) and some windows like Discord and Firefox will animate the first time they're minimized and opened but not again. Other than that, it works great.

My config:

animations = true;

animation-stiffness = 300;
animation-window-mass = 0.4;
animation-dampening = 12;
animation-clamping = true;

animation-for-open-window = "zoom"; #open window
animation-for-unmap-window = "none"; #minimize window
animation-for-transient-window = "slide-down"; #popup windows

[rice7th]

Working amazingly on BerryWM. Only problem is the occasional lag. Here's a video:

animations_1.mp4

[servimo]

Can we have an update with latest patches on this fork of picom, I am using it and it has a lot since I installed it, related to the yshui/picom.

[ghost]

Qtile user here! I tried your fork and it works really well EXCEPT the tag animation
I'm using @Amoebawp config

2023-08-08.16-12-45.mp4

Thats my only problem. I also saw other comments that says basically the same issue so yeah

[FT-Labs]

Will update this soon! Thanks for the response guys

[angrybacon]

Also using Qtile but my issue might not be related to the desktop used. It doesn't seem like animation set for transient windows (Dunst notifications in my case) is respected

Is it missing something on my end?

$ notify-send "Test"
$ xprop

_NET_WM_WINDOW_OPACITY(CARDINAL) = 4294967200
_NET_WM_STATE(ATOM) = _NET_WM_STATE_ABOVE
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NOTIFICATION, _NET_WM_WINDOW_TYPE_UTILITY
WM_CLASS(STRING) = "Dunst", "Dunst"
_NET_WM_NAME(UTF8_STRING) = "Dunst"
WM_NAME(STRING) = "Dunst"

The notification is using the animation from animation-for-open-window rather than animation-for-transient-window

[Darukutsu]

@angrybacon in mean time try

wintypes:
{
  notification = { animation = "slide-down"; };
}

[angrybacon]

Thanks for the workaround. I notice something else just now, the slide-* animations behave like squeeze in that the window grows where I expected them to move into view without being deformed

Is it expected? If so, are there plans for fly-left and fly-right animations?

[Vermoot]

Animations for prev tag and next tag still don't work on awesomewm right?

[Crylia]

Animations for prev tag and next tag still don't work on awesomewm right?

Nope

[FT-Labs]

Working on it rn

[raven2cz]

Configure Animations Specifically for Window Maximization

I've noticed that the current animation settings are not restricted solely to window maximization; they're also being applied to standard window operations. This isn't the desired behavior. When performing routine tasks such as moving, resizing, or simply focusing on a window, these animations are triggered. This not only results in a visual distraction but also slows down the overall user experience, especially when working with multiple windows simultaneously.

Ideally, I'd like the option to configure animations to be exclusive to certain actions, like window maximization. This would help users like myself who appreciate some animations (like maximizing) but find them cumbersome when applied universally across all window actions.

[Vermoot]

I'm inclined to agree with @raven2cz, some things being animated doesn't make much sense. Resizing and moving windows (manually, at least) is made somewhat sluggish by animations being applied.

Additionally, one weird thing I encountered using your fork is this:

2023-09-30.11-31-42.mp4

Context menus seem to be the "same" window when closing and re-opening them, resulting in an animation of their position when re-opening them. The same applies to tooltips.

[Crylia]

I'm inclined to agree with @raven2cz, some things being animated doesn't make much sense. Resizing and moving windows (manually, at least) is made somewhat sluggish by animations being applied.

Additionally, one weird thing I encountered using your fork is this:
2023-09-30.11-31-42.mp4

Context menus seem to be the "same" window when closing and re-opening them, resulting in an animation of their position when re-opening them. The same applies to tooltips.

Does this happen on firefox only, or with all context menus? It could be that firefox (or other apps too) simply hide the context menu and show it when you right click again, and only then they update the position, which would explain this behavior. I hope its possible to not animate the context menu specifically.

[Vermoot]

Indeed it doesn't happen in every app. Happens in Nemo, but not in Nautilus, not in Dolphin, not in Lutris, not in Chromium...

It could be that firefox (or other apps too) simply hide the context menu and show it when you right click again, and only then they update the position, which would explain this behavior.

That makes total sense. I'm not sure it's the case in this fork but in some other picom forks there was a way to disable animations for certain window types.
In the same way, I'd love it if there was a animations_exclude property we could set just like for shadows, blur, etc

[FT-Labs]

Hello,

Guys just as a sidenote, some of the animations can be closed. There is an animations_exclude property on this fork.

wintypes:
{
tooltip = { fade = true; shadow = false; opacity = 0.75; focus = true; full-shadow = false; };
dock = { shadow = false; clip-shadow-above = true; }
dnd = { shadow = false; }
popup_menu = { opacity = 0.8; }
dropdown_menu = { opacity = 0.8; animations = false;}
};

Just set animations to false on the window type you want. It would disable the animations.
As for limiting the animations, like moving and etc. I do not think that would be possible. They can be fastened, but not removed. As you know picom is an external application, it do not have all of the knowledge that DE bundles with renderers have (i.e. gnome).

[raven2cz]

Hello,

Guys just as a sidenote, some of the animations can be closed. There is an animations_exclude property on this fork.

wintypes: { tooltip = { fade = true; shadow = false; opacity = 0.75; focus = true; full-shadow = false; }; dock = { shadow = false; clip-shadow-above = true; } dnd = { shadow = false; } popup_menu = { opacity = 0.8; } dropdown_menu = { opacity = 0.8; animations = false;} };

Just set animations to false on the window type you want. It would disable the animations. As for limiting the animations, like moving and etc. I do not think that would be possible. They can be fastened, but not removed. As you know picom is an external application, it do not have all of the knowledge that DE bundles with renderers have (i.e. gnome).

It's not really about the types of windows (clients) here. If we think about it, it's purely about disabling animations primarily for manual window control via mouse only. In something like Awesome WM, it might be possible to assign a status or environment variable that the environment can read. Awesome WM is highly customizable since it's a framework. Just let us know what's needed and we can supplement.

Besides, I still don't understand, if I wanted animation for a specific task like maximizing, why are there active animations for window movement? Isn't Picom then poorly designed? After all, it's not a problem to provide additional information for Xorg, so why not for Picom too?

I can help with awesome. We've been waiting for years for Picom's behavior to be corrected.

[rice7th]

@FT-Labs I've been testing the fork after it working perfectly in BerryWM, but after switching to AwesomeWM, all animations, especially tag switching animations, are completely broken. Instead of sliding from one side to the other, they just either fade or don't work at all:

2024-01-24.09-30-54.mp4

Also, just like @Vermoot, firefox popup menu animation is completely broken.

Using latest git from your fork and this config

[thenbe]

Some feedback after using the fork for a while:

I was using FT-Labs@b73e6a0 for a few months and it's been working great. The other day I updated to FT-Labs@fe5b416. Immediately, I could tell the animations looked better. I've not closely inspected what exactly changed, but it just "felt better" in general.

UPDATE: I can reproduce the performance issue mentioned below on upstream picom, and so it should not be attributed to @FT-Labs animation fork.

Performance issue

At the same time however, I did notice a performance regression with unexpected high CPU usage. It is triggered by "animations" in the browser such as:

• opening a website with a lot of animations (e.g. https://flashscore.com)
• animations like the youtube spinner (when a video is buffering)
• text being changed on the screen (eg. ai "typing" it's response, where it's being rendered letter by letter)
  • this doesn't happen on https://chat.openai.com, but is very noticeable on something like https://chatkit.app
  • happens on both firefox and chrome

The high CPU usage is not one core being maxed out forever. Instead, two cores take turns getting maxed out one after the other forever (or until the animation stops).

---

• awesomewm: latest version

   System:
    OS: Linux 6.1 NixOS 24.05 (Uakari) 24.05 (Uakari)
    CPU: (24) x64 12th Gen Intel(R) Core(TM) i9-12900K
    Memory: 24.84 GB / 31.13 GB
    Container: Yes
    Shell: 5.9 - /run/current-system/sw/bin/zsh

[Tensaiz]

Did the workspace sliding animation ever get resolved for Awesome?

[yshui]

@Tensaiz (not really an answer to your question, but generally)

unfortunately there will never be a way to do workspace animation reliably on picom's side. So I don't plan to implement that in picom (#1253). OTOH, I might add a way to trigger an animation externally (e.g. picom --start-animation --window-ids=.....), so you can integrate with your window manager that way.

[joaopauloalbq]

@yshui this is one of the most important animations IMO :/

Maybe make Picom a GObject Introspection to add a built-in compositor to the window manager?

I use Awesome btw

[yshui]

@yshui this is one of the most important animations IMO :/

I use Awesome btw

With awesome you should be able to make a dbus request to picom before workspace transition, so you should be able to start animation this way.

[yshui]

hey, #1253 adds some basic animations to picom. can you give that a try and give me some feedback?

[angrybacon]

Note

Posting here since my issue only happens with the fork.

Since a couple months or so (sorry I can't recall a more precise time period) it seems Picom is ramping up memory and CPU usage. At the time of writing this comment, btop indicates 1.7G and around 90% respectively

$ fastfetch
OS: Arch Linux x86_64
Kernel: Linux 6.9.5-arch1-1
Uptime: 2 days, 4 hours, 5 mins
Packages: 917 (pacman)
Shell: zsh 5.9
Display (MD34PRO): 3440x1440 @ 60Hz
DE: qtile
WM: LG3D (X11)
Terminal: kitty 0.35.1
CPU: Intel(R) Core(TM) i5-6500 (4) @ 3.60 GHz
GPU: AMD Radeon RX 6600 XT @ 1.02 GHz [Discrete]
Memory: 9.12 GiB / 15.54 GiB (59%)
Swap: 1.22 GiB / 4.00 GiB (30%)
Locale: en_US.UTF-8

When that happens, I usually kill picom and restart it to fix the issue. Next time that happens, what log or details should I communicate? Other than that the animations are working great so far, since you were looking for feedback.

For reference, here is the configuration I'm using it with https://github.com/angrybacon/dot/blob/9eed042f28e46615dcc2c8e7d484da074a6dd019/config/picom.org

[yshui]

@angrybacon if you know how to use perf, it'd helpful to know where CPU time is spent. For memory usage I recommend building picom with sanitizers to detect leaks. Otherwise try to figure out how to reliably reproduce this problem, so I can investigate.

[angrybacon]

I'm not well versed in perf usage unfortunately but having recorded for about 4h today I arrived at around 50% CPU usage for picom. The report (900MB file) shows me output you might understand better than I do.

I can visit the entries however I don't know what other relevant details I should communicate to you

[yshui]

@angrybacon hmm, this is interesting but doesn't pinpoint the problem. unfortunately your mesa libraries are stripped so I don't know what function is using the CPU. you need to recompile your mesa without stripping, and ideally also enable debug info and frame pointers.

[littleblack111]

nice animations, though very laggy. the lag is very random. sometimes(compiling stuff) at 99% can still run smoothly. but sometimes(under 1-5% load) can be laggy. I am not sure how the animations work. But it's definatly not using gpu. Since my cpu usage went up during the animation, and not gpu usage(im using nvidia)