Animation support

[lanrat]

BlackCapCoder's Compton fork has support for some simple animations.

Would it be possible to add something like this into this fork of compton?
BlackCapCoder's fork is hacky and should be written cleaner if so.

demo: https://www.youtube.com/watch?v=eKwPkiACqF0&feature=youtu.be

[yshui]

I will not actively implement this feature myself, since I think it's out of the scope of compton. but pull requests are welcome if someone want to give this a go.

[phisch]

I have been working on a little proof of concept today to see if this is something that could work in picom, and this is the result:

I have only little c experience, and basically know nothing about how picom works, but that's what i could get after about a day of reading the code and testing stuff.

There are still some bugs and i need more time to get comfortable with everything picom is doing. Might PR in a few weeks once i feel comfortable enough with the quality and functionality.

[phisch]

I'm having an issue when a window shrinks or grows. When one of both happens, it seems like the content of the window is drawing in the new final size instantly. And i can't get the content to scale properly while the transition is running.

@yshui can you maybe give me a clue on how to force windows to redraw their content (during a transition).

[rapiz1]

I have been working on a little proof of concept today to see if this is something that could work in picom, and this is the result:

I have only little c experience, and basically know nothing about how picom works, but that's what i could get after about a day of reading the code and testing stuff.

There are still some bugs and i need more time to get comfortable with everything picom is doing. Might PR in a few weeks once i feel comfortable enough with the quality and functionality.

Good Job!

I'm having an issue when a window shrinks or grows. When one of both happens, it seems like the content of the window is drawing in the new final size instantly. And i can't get the content to scale properly while the transition is running.

@yshui can you maybe give me a clue on how to force windows to redraw their content (during a transition).

I doubt that it's necessary to have windows redraw during the transition. I have a look at the transition of KDE. It seems that windows just crossfade between two image.

[phisch]

Even though it might not be necessary for quick transitions, i would still like to be able to re-render the content during the transition. For the beginning i would like this to happen as often as possible, and later on things like this could be changed with configuration.

For slow transitions, it looks pretty bad if a window goes from very large to very small or vice versa.
I have tried sending a xcb configure window event to set sizes during transition, but this doesn't seem to work either. Still have to do more read-up to figure out how this is properly handled. (or someone could tell me how this works)

[yshui]

Unfortunately it's pretty much impossible to have window contents update smoothly during transition.

From the window's perspective, it's size change request is already acknowledged by the window manager, it's window is already updated to the new size, so it will render content at the new size. The compositor doesn't have a say in this process.

[phisch]

@yshui so the only alternative we have is to grab the pixmap from before the size update, the one after, and transition in between them?

edit: i have no idea how to do that btw. but i'm sure i can figure it out

[yshui]

@phisch ideally, yes.

simple transition is probably enough, like scaling up the before pixmap for example.

[unai-ndz]

@phisch Any updates on this? I will gladly help with testing, looks amazing so far.

[adishourya]

@phisch Same here . I will be more than happy to test it .And I bet loads of people would come up as they are stuck in their home due to COVID19.

[r4dr3fr4d]

@phisch would you happen to have a cloned repo on your page with your modifications? Seems several of us would love to hack along

[jonaburg]

waiting for @phisch might take us forever :) in the meanwhile here's blackcapcoder's compton animation code patched into picom (with only a few adjustments). https://www.youtube.com/watch?v=CqAGhSR3ZtA&feature=youtu.be you can play with it for yourselves at https://github.com/jonaburg/picom

[Iss-in]

Hi @phisch any news on this one ? really waiting for an update on this.

[Icelk]

@phisch Could you share your code of your proof of concept? This would be great, so work can continue work on this feature.
Does anyone want to make animations for the pixmap during the window size animation?

[jzbor]

What is the current attitude to this feature? Is it considered out-of-scope as in it will not be merged? If not what would be required on top of BlackCapCoder, sandsmark and jonaburgs implementation to get it to a mergeable state?

[podiki]

Wondering about this as well. I've been using @jonaburg's fork at times, and animations have been working well for me on XMonad. However, the fork is rather out of date with upstream (here).

Anyone wanna take a run at a PR here for testing with current picom?

[Icelk]

@podiki Do you mean a PR merging @jonaburg's fork?

It'd be nice to have the code from @phisch, who seems to be active, at least in his dotfiles repo,
to compare code and maybe implement great animations!

[podiki]

I won't be picky! I only have experience with @jonaburg's fork (there's even a package for it on the AUR) and it has worked well. But I haven't tried looking at the code to see how well it would separate and could be applied here. Either way, would be nice to have something to apply on top of current picom.

[phisch]

All i did different from others was implementing an ease-in-out function and make sure the animation doesn't stutter (keep high fps).

The main issue with this in picom is that it is basically unclear to know when a window was moved/resized via mouse or when it was moved/resized through a keyboard shortcut or window manager event.

This is why i implemented a threshold of minimum change that the window needs to animate that change. And since i ran this on bspwm and have a high refresh rate (144hz even for bspwm move/resize events), this worked fine for me. But for some other people on 60hz systems, this threshold already was too low and animations could trigger while casually moving a window around. Even if they set a different one that works for them, flicking the mouse while dragging a window would cause this effect again.

Ultimately, picom can't detect how a window was moved or resized, it just knows that it happened, and this isn't enough information for proper animations.

Even if you make this feature opt-in, it's just one more hacky piece of code you have to maintain and drag through picoms development.

My POC was fun while it lasted, but i didn't end up sending a PR because of the reasons above. The code would work much better if there was a way to tell picom that a certain event should be animated (like if window managers could announce that). But since this isn't possible, animations like this will only be feasible in composited window managers. (which have all the info necessary)

I hope this clears things up a bit.

edit: also i don't have the code anymore, but if you really really want to see it, you could probably find it on the unixporn discord where i uploaded it once because people where nagging. (just ask a mod over there, they know the story :P)

[podiki]

Thanks for the detailed explanation and info @phisch, much appreciated.

I'm not sure how things are implemented by @jonaburg for instance, but I found that works really well on XMonad. Probably this type of animation makes the most sense in a tiling WM as you move windows around or spawn new ones, as rarely are you doing anything with the mouse (and I never had errant animations, always seemed to be just on WM events/keyboard shortcuts). Though I see what you are saying, it being a bit of hack when it is not integrated into the WM itself. And I don't know if jonaburg's did animations as in phisch's demo.

Anyway, maybe something to look at for tiling WM especially, where it makes more sense. I might take a look, but won't have a chance for a while. (Always on the lookout for more eye candy)

[lonkaars]

Maybe implementing something like react-spring for procedural animations would be something that could work as a fix instead, as you wouldn't need to detect the difference between mouse/wm movements.

I'm not at all familiar with picom internals though and my c isn't that great, but If there's interest I could try porting some of the animation code into it's own library.

[Icelk]

As a hacky solution to the mouse problem, couldn't Picom get the cursor position and if it's position changed as much as the window's position, don't animate?

The procedural, natural approach seems good; fluid and snappy motion makes or breaks it. Maybe we can implement several algorithms and let the user chose, as with bluring?

I'm also not familiar with picom's internals or C, but would manage some coding as I know Rust. Tell me if you need anything!

[phisch]

@podiki just because it's a tiling wm, doesn't mean it should not work well with a mouse. For reference, i was coding some new parameters for bspwm to swap windows while dragging or not, snap them back into place, make them follow the cursor while dragging or not and some more, and that's what i implemented the picom transitions for. It looked like this:

recording.mp4

(watch the full thing if possible, it's pretty neat)

But i ended up having to rewrite too much code from bspwm which i would not expect baskerville to merge, and that's why i dropped this for now. I do work on my own compositing wm though, which is super early development and not even worth mentioning for now.

[podiki]

@phisch yes, very cool! Oh certainly can be nice to have mouse support in tiling WM, but still I think the point of them is to favor a keyboard-centric approach. Anyway, I was just trying to say that tiling WM will naturally have well-defined stuff to animate, like window spawning to particular tile, swapping tiles, etc. which you wouldn't get in a floating-only WM (there it would be minimize/maximize, maybe snapping windows to the side?). And those tiling motions might mostly/only be done via keyboard shortcut, avoiding the mouse moving problem.

It would be good to see how difficult it is to take the code that is out there to put on top of current picom as a starting point. Unfortunately I won't have time to try for a while, but it'll go on my list.

[phisch]

I don't think the point of tiling wm's is to be keyboard centric. It's to be tiling. The input method has nothing to do with it. I've been using tiling wm's for many years and i use both keyboard and mouse, depending on the situation.

Both tiling and floating wm's have events that are nice to animate. Most floating wm's have shortcuts to snap windows, move them to different workspaces, minimize, maximize, snap leftover windows to empty space. There is a lot in both.

I don't think avoiding the mouse move/resize problem is an acceptable solution. And i would not want yshui or anyone else to drag/maintain hacky code like this throughout the lifetime of picom and its development.

Sry to be a party pooper, but i just think it's not a good idea for picom.
edit: and i wanted it so bad, that i coded it.

[dccsillag]

Thanks!!

Yeah, it's probably wise not to put issues related to my fork in here. I've opened an issue over there for this: dccsillag/picom/issues/1.

No idea what's up with the video. I'll investigate it in a bit.

[tim-kilian]

I really like the animations from @dccsillag (especially the one from @pijulius), but they are really CPU intense and not very usable on a not wired laptop because of battery reasons. Is there a way this will be improved and merged into the main branch? I do use this version of picom and switch it out with the main branch when I am not in a docked state.

[dccsillag]

Is there a way this will be improved and merged into the main branch?

The idea is that I will eventually open a PR. However, there are some issues I'd like to still solve before that.

I really like the animations from @dccsillag (especially the one from @pijulius), but they are really CPU intense and not very usable on a not wired laptop because of battery reasons.

Please open an issue on my fork, we'll see how we can improve.

[tx46]

Hey @dccsillag - how's it going? Any updates? I'm really looking forward to having animations for window movements!

[jzbor]

What happened to the approach used by BlackCapCoder (the jonaburg fork)? It performes much better for me than dccsillags fork (which admittedly has more and nicer animation options) and seems to be reasonably stable. I know that code was never production ready, but at least the concept seems to be valid even for a laptop running on battery...

[phisch]

Correct me if i'm wrong. But i'm pretty sure jonaburg had linear transitions for window move and resize events, and they did not run very smoothly anyway.

Dccsillag has animations for both window move and resize events too, but additionally does easing on the animation, and also is working on a transition between pixmaps in case the size changed, which is a lot more work.

If you ask me, dccsillags fork is by far the most advanced and promising one. I just feel like he lost interest working on it (like I did with my weekend animation project too). I elaborated on this before, but it's just really hard to put weeks of work into something you know is just a hack and doesn't really fit into the project perfectly.

[jzbor]

Yeah I agree, dccsillags animations look MUCH better, but I don't think it is worth the performance hit. I think it is nice to have fast, inaccurate animations good enough that your eyes see what went where and bad enough so that the performance impact is near to 0. Of course for ricing and playing around elaborate animations are nice, but I think for every day usage "bad", fast animations are fine. For me (and possibly many others) having animations is not worth a noticeable decrease in battery life.

[dccsillag]

Hey guys,

I haven't really lost interest -- I mean, sure, I don't have the same drive for it as I had in the first week of development, but I'm still on it.

There are four big things we still need to do on my fork before we get to the point where we'd open a PR:

• Finish merging picom's develop branch into our branch

  I'm working on this; the rounded corners on new backends work some slightly tricky merge conflicts, which I want to tackle with some care.

• Fix the pixmap blending for non-opaque windows: Alpha blending for image content interpolation dccsillag/picom#17

  It's become apparent to me that the only way to really properly, with alpha blending, do this would involve writing a shader, which would require some care (and likely require a major refactor to Picom).

  An alternative, which I felt was quite alright (but others didn't) is to only show the new pixmap, resized to the animating window's size.

  My plan, right now, is to add a config option that controls which of the two methods are used, with a warning when using the former, explaining that things might look odd if you have transparent windows.

• Merge Fixes artifacts by correctly adding old window area to damage dccsillag/picom#22.

  For me, this is the most important -- it has a bunch of fixes. I might cherry-pick the workspace animations there off though, as they are currently very unreliable and should probably be done later -- they are quite complicated by themselves.

• Fix the performance issues: Higher CPU usage / lower battery life with this picom fork dccsillag/picom#27

  This was unexpected, and slightly tricky for me to debug, since performance is quite good for me (though I admit I haven't spent much time on it yet). Will be solved though, as I see no reason for it to be the case.

As for BlackCapCoder/jonaburg's code: for me, their code was consistently buggy, yielding artifacts and choppy animations. Moreover, I felt that their implementation was hacky -- I won't say my implementation is the best thing ever, but I do think it is a tad less hacky than theirs. (Which is natural, since I could see what they had already done and improve on it.) And, even if someone were to try to adapt their code to the current Picom, they would find themselves pretty much redoing a lot of the work I've already done, so I don't think that is a worthwhile effort.

[dccsillag]

Yeah I agree, dccsillags animations look MUCH better, but I don't think it is worth the performance hit. I think it is nice to have fast, inaccurate animations good enough that your eyes see what went where and bad enough so that the performance impact is near to 0. Of course for ricing and playing around elaborate animations are nice, but I think for every day usage "bad", fast animations are fine. For me (and possibly many others) having animations is not worth a noticeable decrease in battery life.

I disagree; firstly, the performance hit will be fixed. But even then, it is inexcusable to ship something with noticeable artifacts / spotty animation. In my book, that's just as bad; it might not bother you that much, but for many people (including me) it can cause literal headaches and eye strain, besides being rather unpleasant.

If it's a separate fork? Sure, do what you want. But for the main picom repo? Then there should be a much higher quality threshold, with only well-rounded features being added.

[jzbor]

I mean if the performance issues and damage tracking is fixed I am all for it! Thanks for the great work!

[dccsillag]

Hey guys,

This is still WIP, but I've now opened a draft PR: #772.

As I said, there are still a bunch of things to do (just look at our issues tab), but I think we're nearly there!

[hexadeque]

What is the reason for implementing animations in the compositor instead of in the window manager?

[phisch]

@hexadeque Implementing animations in a standalone compositor makes it so you can use them with any window manager that comes without compositor.

Animations in a standalone compositor do have issues though, because you can't know how certain events were triggered. You don't know if a window was moved because it was dragged, a shortcut was pressed, or some other internal mechanism in the window manager triggered it.

Doing animations in a standalone window manager on the other hand also has its issues. Since you can't compose, you can't really work with the pix-maps, you can only animate position and size, and size animations will lag horribly because they will trigger the window to re-render itself.

The best way for good animations is to combine window manager and compositor into one, or at least allow them to communicate. That way the window manager can tell the compositor when to animate something, since the window manager is the only part that knows the intention of an event.

[danielnehrig]

maybe its time to extend the wm-spec and wait until wm maintainers adopt ?
also the wm spec accounts for communication between compositors over the display server
does that mean that the api does not expose enough information to make this work properly ?

[shasherazi]

Any updates?

[FT-Labs]

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

Working on it, upstreamed to yshui/next.
Currently workspace/tag switch animations working for pdwm only (close - open - move works for everything), I'll handle it for other window managers when I have time. It has more than +10 animations.

[fdev31]

This branch is excellent, the only I tested which led to no visual defect, stale lines or refresh issue.
I made some experiments, trying to keep it generic (but only tested on qtile)...

https://github.com/fdev31/picom

On current last commit I'm working on a generic desktop change animation... the code is very dirty, but the main feature seems to be there (I'm still testing it).

[SLAYER-CODE]

Worked great for awesomewm: https://github.com/fdev31/picom

[absolutelynothelix]

closing as duplicate of #1121.