yshui
Animation support
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
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.
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.
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 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.
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)
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.
@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
@phisch ideally, yes.
simple transition is probably enough, like scaling up the before pixmap for example.
@phisch Any updates on this? I will gladly help with testing, looks amazing so far.
@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.
@phisch would you happen to have a cloned repo on your page with your modifications? Seems several of us would love to hack along
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
@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?
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?
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?
@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!
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.
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)
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)
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.
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!
@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:
https://user-images.githubusercontent.com/1282767/125138711-70e8dc00-e10f-11eb-8b86-760463e98f0c.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.
@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.
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.
So, I've decided to finally make a serious attempt at this and started my own fork. The idea is to have something that should be ready to [possibly] PR. I have the slight impression (based on past experience) that it is faster/smoother and more robust than @jonaburg's fork (but I have no concrete numbers to back this up, nor have I tested it on any machine but mine). I have not looked at @phisch's code.
Following @lonkaars's suggestion, I implemented spring-based animation. It looks really cool :)
As is currently implemented (for reference, in commit 901ce90), the following config options can be given:
| Option Name | Type | What it controls | Default value |
|---|---|---|---|
animations |
boolean | Whether to enable window animations. | false |
animation-stiffness |
float | Stiffness of the spring for the animation. | 200.0 |
animation-dampening |
float | Dampening (friction) for the animation. | 25.0 |
animation-window-mass |
float | Mass of a window for the animation. | 1.0 |
However, it should be noted that I didn't spend too much time choosing the defaults.
There's also some things that still need to be ironed out. Amongst them:
-
Size animations are okay, but not perfect.
- Window borders get left off of the window during the animation.
- When animating a reduction in size, we don't really have content to put in the animating bit.
-
Moving a window with the mouse. Should it be instantaneous (as in a typical DE)? If so, is there a [mostly] reliable way to detect it (maybe using some sort of window property?); Or should we use spring animations? Maybe we should add a config option to toggle between these two options!
[This is the point raised by @phisch.]
I ended up liking window movement with the mouse with the spring animations. But I bet there are people out there who would prefer otherwise.
-
Better defaults.
-
Check that the config values are valid (i.e.,
stiffness >= 0,mass >= 0,dampening > 0). -
Clamping to ensure the animated positions/sizes are valid (in the screen / positive).
-
Implementation "details:" (Disclaimer: I'm not really familiar with Picom's code).
- When we are animating a window, do we need to update
managed_win::reg_ignore? - When we are animating a window, do we need to update
managed_win::border_col(Which is marked as "changing based on window size")?
- When we are animating a window, do we need to update
-
Test on more configs. I've tested on a few config combinations, but not enough. Are there any configuration options which mess up animations, or get messed up because of animations?
If anyone wants to help, just trying out the code and reporting any problems would be amazing!
I'm also attaching a demo of my code. Ignore the temperature, that's about what my idle temperature (without picom running) is looking like as well.
https://user-images.githubusercontent.com/15617291/125180705-a1924980-e1d3-11eb-9351-d0ffec835d5b.mp4
EDIT: I think the main problem here remains being mouse inputs, but now we have a nice playground to play around in. Also, I [hopefully] fixed the video playback.
@dccsillag wow fast work! (my secret plan of commenting and someone jumping in with "I can do it!" worked...). Impressive! But your video is showing as "corrupt" here.
I did a quick modification of a PKGBUILD to install, no problems there. However, with animations enabled any window motion makes things go crazy (jump around, jitter, won't stop moving, flying around). My config (besides adding animations = true;) is here: https://github.com/podiki/dot.me/blob/master/picom/.config/picom.conf Perhaps the only notable thing is that this is on a 4k screen. (For comparison, same setup on jonaburg's fork worked well without any animation problems.)
Anyway, not sure if we want to clog up this issue or find somewhere else to troubleshoot. Happy to test, and would be happy to contribute but will be away soon for a few weeks.
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.
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.
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.