komorebi
komorebi copied to clipboard
feat(animation): bring in changes from #597
This commit contains all the changes of #597 to make it easier to rebase with the latest changes on master post-v0.1.21.
Hi, @LGUG2Z - I understand you must be filled with work around other stuff, was just wondering on the progress with this? Please let me know if you need some help with it and I'll be happy to help wherever possible.
Animations in Komorebi would be great to have! 🎉 Thanks for the work, @raggi and @LGUG2Z 🚀
The main challenge we've seen in testing is that the animations cause chrome & cef windows to render in the wrong place - they start to render outside of their client rect (which isn't visible). This is sort of a chrome bug, but one that the animations robustly trigger.
I was experimenting with some other ways to do some of the actions that Komorebi takes recently, and they seem to work ok on Windows 11 so far, and might help with this problem - specifically avoiding attaching external input handler threads to the processes during window moves and focus events - but this relies on behavior we're not supposed to be allowed to do - lots of testing required.
@raggi would we have to wait for this chrome bug to be fixed before getting this pr merged? if yes, does it affect only google chrome or any other derivatives like edge and vscode, discord, etc ?
I cant wait for komorebi to have animations just like on hyprland, it's the last missing piece of software I needed to make my workflow on windows same as on linux :)
This will probably be released as an "experimental" option (ie. you may have to do a hard restart of apps impacted by bugs and lose data if you can't save beforehand) in v0.1.26; hopefully someone will want to stabilize it enough that they'll drive themselves crazy finding a way to fix these bugs on our end vs. waiting for Electron apps to have this fixed via Chromium. 😅
@thearturca things generally look ok with the latest changes I've pushed along with the latest rebase, however I am noticing CPU spikes in Desktop Window Manager, probably caused by our animations, whenever I am moving windows around with animations enabled. Can you think of any way we could optimize our calls here? 🤔
@thearturca things generally look ok with the latest changes I've pushed along with the latest rebase, however I am noticing CPU spikes in Desktop Window Manager, probably caused by our animations, whenever I am moving windows around with animations enabled. Can you think of any way we could optimize our calls here? 🤔
I've scrolled through the new commit. There is only one way to optimize this. Reduce Window API calls count.
First we can mess around with target frame rate
here https://github.com/LGUG2Z/komorebi/blob/feature/animated-move/komorebi/src/animation.rs#L466
Currently its hardcoded to 240 frames per second which is a bit high. We can make configurable and defaults to 60. Or we can make it equals to max refresh rate of all monitors plugged in. So less frames == less windows api calls.
Second we should consider about how often we call invalidated rect
https://github.com/LGUG2Z/komorebi/blob/feature/animated-move/komorebi/src/window.rs#L194 and does it increase cpu usage on DWM. Maybe comment it out and see if anything changes.
Also we should rector this line https://github.com/LGUG2Z/komorebi/blob/feature/animated-move/komorebi/src/window.rs#L190 to if progress == 1.0
and swap if-else statements because some ease functions could generate progress more than 1.0
. It would cause position_window
call which does more thing than move_window
call. It requires testings and benchmarks.
Adding a very nice demo of the the current state of this PR from AmN on Discord:
https://github.com/LGUG2Z/komorebi/assets/13164844/8e891a80-a3fd-4e71-8477-852b694ffa22
- Borders are disabled on
komorebi
andcute-borders
is being used to modify the native Windows accent colours
Adding a very nice demo of the the current state of this PR from AmN on Discord:
Recording_2024-06-20_033025.mp4
- Borders are disabled on
komorebi
andcute-borders
is being used to modify the native Windows accent colours
nice!
I think we are at the point where this can now be merged into master
and have appropriate documentation added outlining this as an experimental feature with the usual "This feature is not considered stable, and you may encounter visual artifacts from time to time" blurb.
I'll take some time this weekend to update the documentation and hopefully we should be able to get this merged for v0.1.28
🤞
This has now been merged to master - I'll find some time this week to start working on the docs in prep for the next release