animations

[absolutelynothelix]

since there are multiple open issues requesting animations i decided to group them into a single issue to have a more or less centralized discussion, ease the progress tracking and reduce the amount of open issues.

there is also a thread in the #development channel on the discord server to ease the communication between developers interested in implementing animations.

feel free to reserve one of the first posts in this issue if you're interested in structuring it even more.

related issues:

• Animation support #217;
• [Feature/Pull request] Add BlackCapCoder's window animation code. #420;
• [Feature Request] Sliding animations for workspace switches. #635;
• Need help testing animations #1052;
• [Feature Request] Add wobble as a animation #1115;
• [Feature Request] Include animations based on https://github.com/FT-Labs/picom or personal #1116.

related discussions:

• todo.

related pull requests:

• Adding transition (cleanup) #766;
• Implement window animations #772;
• Animation PR #1032;
• @FTLabs generalanimation branch merged with next with original git history and compiling (Animation PR) #1109.

forks that implement animations:

• todo.

feel free to post here or ping me on the discord server about additions to the lists above.

[ghost]

Forks that implements animation:
https://github.com/pijulius/picom (Best animation)
https://github.com/jonaburg/picom {Slight animation changes}
https://github.com/FT-Labs/picom (Intended for his own fork of dwm)
https://github.com/fdev31/picom (Fork of FT-Labs Picom which somewhat work better than FT-Labs picom)
Thats all i can remember lol

[dccsillag]

... and mine, https://github.com/dccsillag/picom, which is what pijulius, FT-Labs and fdev31 forked from (and what the long-standing PR #772 was from).

[ghost]

Oh yeah i kinda forgot about yours.... Thanks for reminding me though :D

[NotMurPh]

i can't check out the discord thread, looks like the invitation link has expired! i would be happy to hear an update about picom animations 🫠

[absolutelynothelix]

i can't check out the discord thread, looks like the invitation link has expired!

thanks for pointing out. i copied it from the discord badge in the readme but it turned out that it wasn't updated when it was changed so i updated it both in the readme and here.

i would be happy to hear an update about picom animations 🫠

unfortunately, there are no updates.

[allusive-dev]

Still want animation support.

Done.

Here is my public, actively maintained, on the AUR fork of pijulius picom.

Now on NixOS and Nixpkgs and I am always looking to add new features.

Links:

https://github.com/allusive-dev/picom-allusive
https://wiki.archlinux.org/title/Picom_Allusive
https://aur.archlinux.org/packages/picom-allusive
NixOS

[yshui]

Hi, I want to quickly ( 🤞 ) merge animation support after v11 release (which should be in the next few weeks, again 🤞 ).

looks like @FT-Labs' fork is the most comprehensive one? so maybe i will consolidate all the PR's around that.

now, I realized I never asked if @FT-Labs wants to merge their branch into this repo, i just assumed they do 😅 I will still do this either way (these are all open source after all), but if @FT-Labs wants to, we can work together and sort this all out faster than I can with only current picom developers.

[yshui]

And if @FT-Labs's fork has missing features, or there is another fork I need to look at, or something, please leave a comment.

[yshui]

And I would definitely appreciate @dccsillag's help as well if he has more time and is able to.

[FT-Labs]

Hello @yshui,

Yes, I'm totally up for it. That would be great, because this is a work that needs more than 1 person. Any help would be appreciated, I would be glad to explain what I have done until now and explain all of the steps.

[jasper-clarke]

@yshui
I've forked the next branch and implemented the animations from Compfy which came from pijulius which are modified from dccsilag.
If you want me to make a PR let me know.
https://github.com/jasper-at-windswept/picom

[dccsillag]

And I would definitely appreciate @dccsillag's help as well if he has more time and is able to.

I'd be happy to help. (Still a bit strained for time, though!)

[zeorin]

I tried out @jasper-at-windswept's fork because I was curious, and the animations are cool, but the following would need some work, imo:

• interaction with shaders, currently the shader is unapplied and then only reapplies a bit after the animation has finished.
• interaction with blur and shadows, currently the shadows lag behind the actual window's animation and the space in between blurred.
• interaction with mouse-driven changes to window position and size

It would also be great to be able to set all animation settings using rules, rather than only being able to exclude windows from opening and unmapping animations. This would allow one tweak animations in a very fine-grained way, it'd be great for e.g. menus, docks, launchers, notifications, etc.

Here is a recording (i3wm):

picom-animations.mp4

For reference, my config is here: https://github.com/zeorin/dotfiles/blob/07f0c9bf789f8baebc40afd3b06c5586b7a0caf8/home-manager/home.nix#L2618-L2803

[yshui]

@jasper-at-windswept I intend to take from @FT-Labs 's fork, as IIUC it is the most up-to-date version.

[yshui]

Hello @yshui,

Yes, I'm totally up for it. That would be great, because this is a work that needs more than 1 person. Any help would be appreciated, I would be glad to explain what I have done until now and explain all of the steps.

Hi, can you open a PR from your branch?

[jasper-clarke]

@jasper-at-windswept I intend to take from @FT-Labs 's fork, as IIUC it is the most up-to-date version.

No problem. Looking forward to animations in v11!

[XoDefender]

Also feel free to try out my fork, it is based on FT-Labs and has animation customization throughout: rules, xprop, wintypes. May be helpful to take particular parts from it (https://github.com/XoDefender/picom)

[raven2cz]

@raven2cz You can do so via window rules. Assuming you already know how to assign properties to the required windows, you can add a similar rule such as:

rules = (
  {
    match = "MANUAL@ != 1";
    animations = ( { triggers = [ "geometry" ]; preset = "geometry-change"; }, );
  },
),

I have just written this out in this text box, so there may be a few syntax errors, but this general idea will work

@kingdomkind I applied your suggested settings in Picom. The MANUAL has been configured correctly in Awesome, but all client windows appear fully black and are not being rendered by Picom. This seems to be causing significant rendering issues.

[yshui]

@raven2cz the rule you added shouldn't change rendering when the animation is not triggered though.

[kingdomkind]

@raven2cz You can do so via window rules. Assuming you already know how to assign properties to the required windows, you can add a similar rule such as:

rules = (
  {
    match = "MANUAL@ != 1";
    animations = ( { triggers = [ "geometry" ]; preset = "geometry-change"; }, );
  },
),

I have just written this out in this text box, so there may be a few syntax errors, but this general idea will work

@kingdomkind I applied your suggested settings in Picom. The MANUAL has been configured correctly in Awesome, but all client windows appear fully black and are not being rendered by Picom. This seems to be causing significant rendering issues.

This worked fine for me, using my own window manager (assuming the syntax is fine)

[raven2cz]

@raven2cz You can do so via window rules. Assuming you already know how to assign properties to the required windows, you can add a similar rule such as:

rules = (
  {
    match = "MANUAL@ != 1";
    animations = ( { triggers = [ "geometry" ]; preset = "geometry-change"; }, );
  },
),

I have just written this out in this text box, so there may be a few syntax errors, but this general idea will work

@kingdomkind I applied your suggested settings in Picom. The MANUAL has been configured correctly in Awesome, but all client windows appear fully black and are not being rendered by Picom. This seems to be causing significant rendering issues.

This worked fine for me, using my own window manager (assuming the syntax is fine)

@kingdomkind Thanks for the info, could you share a link or file with your configuration? I'll try your setup or compare the changes. After all, my picom.conf has accumulated a lot over the years. Syntax is same.

[kingdomkind]

@raven2cz You can do so via window rules. Assuming you already know how to assign properties to the required windows, you can add a similar rule such as:

rules = (
  {
    match = "MANUAL@ != 1";
    animations = ( { triggers = [ "geometry" ]; preset = "geometry-change"; }, );
  },
),

I have just written this out in this text box, so there may be a few syntax errors, but this general idea will work

@kingdomkind I applied your suggested settings in Picom. The MANUAL has been configured correctly in Awesome, but all client windows appear fully black and are not being rendered by Picom. This seems to be causing significant rendering issues.

This worked fine for me, using my own window manager (assuming the syntax is fine)

@kingdomkind Thanks for the info, could you share a link or file with your configuration? I'll try your setup or compare the changes. After all, my picom.conf has accumulated a lot over the years. Syntax is same.

https://github.com/kingdomkind/pika-archconfig/blob/5414fc26590bad61d3f7f5b437e1a91d0b50c6fb/picom.conf
It's commented out at the bottom, but is the same as my original post

[raven2cz]

@raven2cz You can do so via window rules. Assuming you already know how to assign properties to the required windows, you can add a similar rule such as:

rules = (
  {
    match = "MANUAL@ != 1";
    animations = ( { triggers = [ "geometry" ]; preset = "geometry-change"; }, );
  },
),

I have just written this out in this text box, so there may be a few syntax errors, but this general idea will work

@kingdomkind I applied your suggested settings in Picom. The MANUAL has been configured correctly in Awesome, but all client windows appear fully black and are not being rendered by Picom. This seems to be causing significant rendering issues.

This worked fine for me, using my own window manager (assuming the syntax is fine)

@kingdomkind Thanks for the info, could you share a link or file with your configuration? I'll try your setup or compare the changes. After all, my picom.conf has accumulated a lot over the years. Syntax is same.

https://github.com/kingdomkind/pika-archconfig/blob/5414fc26590bad61d3f7f5b437e1a91d0b50c6fb/picom.conf It's commented out at the bottom, but is the same as my original post

@kingdomkind Interesting your configuration works! I'll try to set it all up with it. Thank you very much. This original configuration of mine causes the windows inside not to render at all if I uncomment the animations and rules at the bottom:
https://github.com/raven2cz/dotfiles/blob/main/.config/picom/picom.conf

But that's just for your information. I'll then try to make some compromise between the settings. Thanks!

[yshui]

@raven2cz i figured out what's wrong, should be fixed now.

[g-wizzy]

Not sure if it is intended, but I find the following effect a little jarring:

During the slide-in animation, the rounded corners are ignored until the animation is finished. What I mean is, in this example, as the window slides down, the upper corners aren't rounded. I increased the duration in order to make it more apparent.

picom-anim.mp4

Is it meant to look this way ? Or am I missing a parameter to have the corners always be rounded ?

[yshui]

@g-wizzy but the rounded corner is still there? or do you mean the corners at the top?

corners are still rounded, but the top half of the window is cropped out so you don't see the top corners.

[g-wizzy]

@yshui The fact that the corners are cropped during the animation is what I am talking about yes. During the slide-in, the corners at the top are squared, and I was asking if this was intentional.

[yshui]

yeah, slide-in crops the window.

[PassiveLemon]

is there currently a way to disable animations for a window rule?

[absolutelynothelix]

@PassiveLemon, yes, using the rules option. see the man page for details.

[PassiveLemon]

@PassiveLemon, yes, using the rules option. see the man page for details.

All I see is how to define animations for specific window types, there's no obvious way to disable them.

Well I effectively disabled them by setting these for the match.

animations = ({
  triggers = [ "open", "show", "close", "hide", "geometry" ];
  suppressions = [ "open", "show", "close", "hide", "geometry" ];
})

Definitely not a solution I like though. Maybe just a simple animations = false?

[jdujava]

@FugitiveDock282 this is a limitation with blending the window content before/after the geometry change. the way we do the blend works for opaque windows, but for semi-transparent windows this happens. (also notice how the blur area doesn't follow the window body during animation). geometry animation is experimental after all.

@yshui Would it be hard to make the blending respect the transparency, such that it seamlessly transforms from initial window opacity to the final one? Perhaps somehow by shifting the opacity from initial "saved image" to the resulting window, such that the total opacity is transitioning smoothly?
Otherwise the transitions look wonderful!

[Celibistrial]

Is it possible to have the workspaces slide left / right depending on where you switch from.(like hyprland)

Eg if im on workspace 2 and go to workspace 3 , it should slide to left and if im on workspace 3 and go to worksapce 2 , it should slide to left

PS: The animations look very good, nice job!

[FugitiveDock282]

Is it possible to have the workspaces slide left / right depending on where you switch from.(like hyprland)

Eg if im on workspace 2 and go to workspace 3 , it should slide to left and if im on workspace 3 and go to worksapce 2 , it should slide to left

PS: The animations look very good, nice job!

I believe that should work if you enable animations on geometry change?

[absolutelynothelix]

@Celibistrial, it was discussed multiple times and, well, it's technically possible, but this behavior severely lacks standardization and there are plenty of caveats and edge cases, so it'll be a mess to implement for a standalone compositor unlike hyprland.

[Celibistrial]

@Celibistrial, it was discussed multiple times and, well, it's technically possible, but this behavior severely lacks standardization and there are plenty of caveats and edge cases, so it'll be a mess to implement for a standalone compositor unlike hyprland.

Oh alright, i don't know how compositors work but would it be possible to dynamically call animations?(tell picom to play side-in animation from a script)
Then people can just make a script that detects workspaces changes and plays the correct animation, would enable a lot more than that too.

[absolutelynothelix]

@Celibistrial, i think yshui told exactly about this somewhere.

[DarioDarko]

rules =
(
	{
		match = "focused";
		opacity = 0.9
	}
);

animations =
{
	triggers = [ "close", "hide" ];
	preset = "slide-out";
	direction = "down";
	duration = 0.15
}

while sliding out the .9 opacity setting is ignored, which looks a little weird. it changes to 100% opacity during the animation. this is not happening with (dis)appear tho. good job btw, the new animations are pretty cool 👍

[absolutelynothelix]

@Celibistrial, i guess this is what i was thinking and talking about: #1262 (comment).

[yshui]

@DarioDarko while animation is running the values produced by the animation script take precedence over other window rules. you can easily fix this by adding a curve for opacity in you animation script.

that being said, i guess for the presets i should include that by default so it works more seamlessly.

[yshui]

@jdujava

Would it be hard to make the blending respect the transparency

let me explain a bit how it works now.

normally, when you do alpha blend, this is what you do:

$$C = C_a \times (1 - \alpha) + C_b \times \alpha $$

where $C_a$ is the RGB color value of the background image, $\alpha$ is the alpha of the pixel, $C_b$ is the color value of the image you are painting over the background.

And when you interpolate between two images, this is what you do:

$$C_b = C_{old} \times t + C_{new} \times (1-t)$$

where $t \in [0, 1]$ is the interpolation factor, $C_{old}$ is the "old" image, and $C_{new}$ is the "new" image.

Now, what we really want to do is to alpha blend the interpolated image over the background, so we substitute $C_b$ in the first equation with the second equation, and rearrange the result:

$$C_{tmp} = C_a \times (1 - \alpha_{old}) + C_{old} \times \alpha_{old}$$ $$C = C_{tmp} \times (1 - \alpha_{new}) + C_{new} \times \alpha_{new}$$ $$\alpha_{old} = \frac{\alpha \times t}{1 - \alpha_{new}}$$ $$\alpha_{new} = \alpha \times (1 - t)$$

in other words, alpha blend with the interpolated image, can be turned into 2 alpha blends, first with the old image then with the new image. and this is what picom does to avoid adding a completely new type of operation - interpolation.

there is a catch though, we assumed all the color values are RGB, i.e. they don't have alphas of their own. I haven't figured out the math (and indeed i don't even know if the math will work out the same way) if the colors do have alpha values.

[jdujava]

If we write interpolation as (at beggining we have $C(0)=C_{\text{beg}}$, and we end with $C(1)=C_{\text{end}}$)

$$C(t) = (1-t)C_{\text{beg}} + t C_{\text{end}},$$

then it is the same as alpha blend

$$C(\alpha) = (1-\alpha)C_{\text{background}} + \alpha C_{\text{window}}$$

under identifications $t\equiv\alpha$, $C_{\text{beg}}\equiv C_{\text{background}}$, and $C_{\text{end}}\equiv C_{\text{window}}$, right?
So in my mind there is no need for "completely new type of operation — interpolation".

My thinking is that the following could work. Lets denote the old/new window colors as $C_{\text{old/new}}$, and old/new background colors as $C_{\text{background,old/new}}$. Then we begin with the color

$$C_{\text{beg}}=(1-\alpha_{\text{old}})C_{\text{background,old}} + \alpha_{\text{old}}C_{\text{old}}$$

and we end with

$$C_{\text{end}}=(1-\alpha_{\text{new}})C_{\text{background,new}} + \alpha_{\text{new}}C_{\text{new}},$$

so we just have to interpolate/blend between them using

$$C(t) = (1-t)C_{\text{beg}} + t C_{\text{end}}.$$

This should work generally with different colors and their alphas, and even different background colors.
What are your thoughts @yshui?

[Jipok]

Animations are great, but are there any plans to add some API, IPC, or switch to using a full-fledged language(like lua) for animations/scripts? This is sorely lacking.
For example, I would like to "launch" animations directly from my AwesomeWM config. Because I want to make animations like in niri.
https://github.com/YaLTeR/niri?tab=readme-ov-file#video-demo
Check out how great animations work in niri, especially switching workspaces. With the current capabilities of picom, I can't imagine doing this. Unless I somehow dynamically change the window classes from awesomewm so that picom displays the desired animation, but it seems to me that this will not work very well.

And I think people have many ideas on how to use animations, and although from a technical point of view there is nothing complicated in such desires, but the limitations of DSL will not allow you to do anything like this.

[absolutelynothelix]

done in #1220, #1253, #1303, #1305, #1308 and #1310 (included in the v12-rc1 pre-release).

closing as done.

[absolutelynothelix]

leaving this pinned for a while for further discussion but prefer creating new issues for bug reports and feature or enhancement requests.