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"

[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)

[vredesbyyrd]

@yshui

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.

I'm using awesomewm, the animations from your next branch look and work great. Although I am curious about sending a dbus request to picom for workspace transitions, has this been implemented? Looking at the documentation did not get me any closer. Any pointers would be very appreciated!