Implement window animations

[dccsillag]

This adds window animations, and would solve #217. We use spring-based animations -- they are visually pleasing and handle interactions well, compared to parametric interpolation/animation.

This is still a work in progress -- remaining issues are being tracked in my fork's issue tracker.

I feel it's also worth mentioning that this might have quite a bit of code in common with #766 (I haven't looked into it very carefully). However, with this code the work over at #766 should be easily doable (~10 more lines of extra code), while it probably wouldn't work the other way around.
I've also just stumbled into #771 (comment) -- this PR should make this very easy (because of the changes to the compose backend operation).

[Suyashtnt]

Window animations seem to break severely on awesomeWM, does anybody know the cause of it?

[dccsillag]

hey, hope you've been doing alright! have you had any luck so far? patiently waiting regardless :D

I'm afraid I've had no luck. I'm sorry for the inconvenience, but I've really had little to no time to work on this.

Window animations seem to break severely on awesomeWM, does anybody know the cause of it?

If it's not already in the issue tracker, then please open one, explaining what you mean by "break severely" (possibly with screenshots/screen recordings).

I recently happened to test this on a plain-ish AwesomeWM config and it worked flawlessly -- perhaps you have some configuration causing some conflict? (But please still report the issue.)

[AlexvZyl]

@dccsillag Please don't feel pressured. This PR does not put food on your table. Do it in your time.

[Borber]

I'm looking forward to it! I hope that my phobia of choice will be cured by the official version!

[joaopauloalbq]

Guys just send messages that have some relevance, this is a pull request not a chat room.

I also want this feature but this kind of thing just annoys developers...

[dccsillag]

Just to add to @joaopauloalbq's comment above:
There's no need to worry about me having forgotten about the work here or giving up on it. It's consistently in my personal TODO lists, and if anything is to change about my plans regarding this PR I will clearly say so here.

So let's try to leave this PR's discussion to messages regarding the actual code. (While I don't personally mind comments asking for updates all that much [as long as they are in moderation, as they have generally been], keep in mind that many other people are also subscribed to this PR, and such comments can be very noisy to them.)

[Monsterovich]

@dccsillag Could you please update this PR with "next" branch? I just wanted to take a look into this.

[soanvig]

FYI: I'm using implement-window-animations branch from @dccsillag repo for a month now, and I have no serious issues. Some slight things could be potentially improved, but it looks very good for a v1 of this feature.

[Monsterovich]

FYI: I'm using implement-window-animations branch from @dccsillag repo for a month now, and I have no serious issues. Some slight things could be potentially improved, but it looks very good for a v1 of this feature.

The "next" branch has some important fixes including fixes for memory leaks.

[dccsillag]

@dccsillag Could you please update this PR with "next" branch? I just wanted to take a look into this.

I'm waiting on @FT-Labs for that (as per the discussion in #911). BTW, @FT-Labs, any prediction on when we can get a PR on my fork rolling? (Once we have that, I can also start pitching in to help.)

[FT-Labs]

Hi @dccsillag , I waited for some time for the latest memory leaks issue's to get resolved, in case of merge conflicts. I've working on it now, but I got stuck on some edge cases, let me list:

Picom uses viewport, but for some workspace animations to work (e.g minimize, maximize) center of the current monitor must be known, because animation's will flow towards there. I don't want to add an xinerama dependency to picom for it, if you are okay with that I will just add another dependency.
As for why is this needed, if there are multi monitors, picom will only have one root window, which is the sum of total monitors. Animations will go to center of summed multiple screens, which doesn't seem good.
Other minor issue is, I think you might have noticed windows flash when you spawn a window with transparency, or resizing windows with transparency.
In my case, since I only support for my current packages, st and pdwm. I could only solve this issue with adding a line in paint_all_new(...) function, with this statement:

				if (resizing && (!is_focused || !w->opacity_is_set)) {
					process_window_for_painting(ps, w, w->old_win_image,
									1.0 - w->animation_progress,
									&reg_bound, &reg_visible,
									&reg_paint, &reg_paint_in_bound);

However by doing this, everyone must edit their configuration file properly with their respected transparent applications, like the one in below:

opacity-rule = [
  "100:class_g = 'St' && focused",
  "50:class_g = 'St' && !focused",
  "100:fullscreen",
];

I am trying to figure these out, but since from the beginning I have only edited the source code for specific applications like st and pdwm, I'm kind of having a hard time to change these. I even did not add any extra ewmwh tags like _NET_CURRENT_DESKTOP and _NET_CURRENT_WM, because I did not needed them. But since I'm trying to make this more general so that it will work on any WM/DE, it is kind of giving me a hard time to revert these changes.

[dccsillag]

Thanks for your work and quick notice!

I think you can leave the "flickering" issue (it's more of a pixmap blending issue, really) to me -- I have a couple of ideas on how to at least work around it. So maybe remove the program-specific workaround and once we get a PR going I can tackle it.

Now, the screen center issue is trickier. My guess is that there isn't really going to be some way other than just using Xinerama -- and even if there is, it's probably such a hack that we'd be better off just accepting we have one more dependency now. But I'm not the one to check whether to add a dependency or not, that's up to @yshui.
Nevertheless, here's what I propose regarding this: let's start without these monitor-sensitive animations. Once we have all the rest wrapped up, we can look into adding them back (possibly even as a follow-up PR for yshui/picom).

[NicTanghe]

is it dead ?

[absolutelynothelix]

a wild absolutelynothelix appeared

@FT-Labs, @dccsillag, xinerama is gone and we're using only the x randr extension starting from 986b3c1. it's more powerful than you think and we're already getting and storing (not explicitly, though) dimensions of all available monitors. furthermore, there is a function that can tell if a window is entirely on a particular monitor. see the x_update_randr_monitors function in the x.c and the win_update_monitor function in the win.c. you can use or extend these functions for your needs (or create new ones). it's okay to use and depend on the x randr extension.

[FT-Labs]

@absolutelynothelix This is perfect! Thank you.

FT-Labs@36e6b73

[FT-Labs]

@absolutelynothelix For this to work properly with animations, I needed to delete first statement in the update function.

void win_update_monitor(int nmons, region_t *mons, struct managed_win *mw) {
	mw->randr_monitor = -1;

Will deleting this assignment break anything? If this exists, animations won't work properly because monitor will get reset on each move.

FT-Labs@bb2b480

[absolutelynothelix]

@FT-Labs, the current implementation of the win_update_monitor function assigns a monitor number to a window only if a window is entirely on a particular monitor. if a window is present on multiple monitors, the assigned monitor number will be -1. i haven't looked at your fork yet, but you may want to always assign a monitor number to a window, for example, by calculating intersection areas of a window with each monitor a window is present on, comparing them and assigning a monitor number which has the largest intersection area. in the example below the window 1 will be assigned to the monitor 4 because it has the largest intersection area with it:

┌─────────────────────┬─────────────────────┐
│monitor 1            │            monitor 2│
│                     │                     │
│                     │                     │
│                     │                     │
│               ┌─────┼──────────────┐      │
│               │     │              │      │
│               │     │              │      │
├───────────────┼─────┼──────────────┼──────┤
│               │     │              │      │
│               │     │              │      │
│               │     │              │      │
│               │     │      window 1│      │
│               └─────┼──────────────┘      │
│                     │                     │
│monitor 3            │            monitor 4│
└─────────────────────┴─────────────────────┘

but i'm not sure what we should do if there are two or more equally largest intersection areas.

afaik, a monitor number assigned to a window by the win_update_monitor function is used only by the crop-shadow-to-monitor option currently, so you should test if your changes are breaking it. an example how it should look like is in the #995.

[FT-Labs]

@absolutelynothelix I see, that is probably why the issue occurs.

All of the enhanced DE (e.g gnome, kde...) tends to minimize (iconify, unmap event) other windows when switching to another desktop/workspace. However this might not be the case for some window managers. For example, in dwm, there is no unmap/minimize or iconify event. Windows only get hidden to someplace in the display outside of monitor positions. For example they either get hidden on to leftmost monitor - client width, or in y position 0 - client height, without unmapping it. Do you have any idea how we can overcome this issue? Deleting first statement works because it won't get overridden by -1 if client was hidden to any place, but before it has an assigned monitor.

For example this is how it looks on my window manager

        showhide(c->snext);
        XMoveWindow(dpy, c->win, c->mon->wx + c->mon->ww / 2 - WIDTH(c) / 2, - (HEIGHT(c) * 3) / 2);

[absolutelynothelix]

@FT-Labs, try rewriting the win_update_monitor function implementing the mechanism described above and not assigning the monitor number -1 to a window in the beginning of the function. it should be fine both for the crop-shadow-to-monitor option and for animations, but i can't test it right now. if you don't have multiple monitors to test if it breaks the crop-shadow-to-monitor option, you can use the xrandr to split a single physical monitor into two or more virtual monitors just like i did in the pull request mentioned above.

[alexhulbert]

I'm probably like one of the only people who actually uses the picom window-shader-fg option so this is probably low priority, but I noticed it doesn't work during and after transitions. The issue persists for about 1-3 seconds after the transition ends (or longer if I don't focus the window).

[yshui]

@FT-Labs hi, can you open a PR from your branch? I will close the other animation PRs.