search

flyingpie / windows-terminal-quake

Enable Quake-style dropdown for (almost) any application.
https://wtq.flyingpie.nl
MIT License
598 stars 39 forks source link

Smooth toggle animations + support for different animation functions #75

Closed timmolderez closed 3 years ago

timmolderez commented 3 years ago

Hey @flyingpie ,

I only just started playing with Windows Terminal, and it's perfect in combination with windows-terminal-quake! I really like it a lot! The only thing I couldn't get over was the open/close toggle animation being a little choppy, so I started digging through the code and saw that the Task.Delay statements in Toggler.cs are the culprit.

Smooth toggle animations

To make the toggle animation really smooth, I ended up rewriting how the Toggle function works. Instead of a "move the window a little, then wait a little"-loop, it now just is a "move the window"-loop; no waiting/sleeping at all.

To know the correct position of the window at any time during the animation, I use a Stopwatch to measure many milliseconds have passed since the time the animation was started. (e.g. if ToggleDurationMs is set to 200 ms, and we know 100ms have passed, then the window has to be in the "half-open" position.) Since the code now never sleeps, I also checked if this would cause CPU usage to rise during a toggle, but I can't really tell the difference .. CPU usage stays very low, no matter how often I try to mash Ctrl+` :p (I only tested it on my computer though; would be good to have a few more people try it out of course)

Animation functions

The other part of this pull request is that I also added several kinds of "animation functions". A new "ToggleAnimationType" setting was added to the .json settings file for this. Currently the window moves at a constant speed during the open/close animation, but this PR adds several more options. (For example: first go fast, then slow down.. or the other way around .. You can get an idea of what the different options look like here: https://easings.net/ ) Most of the code for this is in the Toggler.AnimationFunction method.

That's it; let me know what you think :) .. and thanks again for making this awesome project!

Cheers, Tim

flyingpie commented 3 years ago

@timmolderez Thank you for the PR! I'm definitely gonna take a look at this.

For your information, the reason for the wait had to do with some of the pc's where I run this on not enjoying the high update rate. Especially laptops running from battery got varying results. Not necessarily that the cpu blew up, but the actual time it took to go from top to bottom varied greatly. So that's what got me to add the delay, to make the overall animation time more consistent.

That said, I'm happy to have the delay configurable to be non-existent. Not sure if setting it to 0 would do that, maybe we could just add a line that skips the delay entirely if the setting is at or below 0.

Have you tried setting the animation delay to 0 and see what that does on your system?

timmolderez commented 3 years ago

I have played with it some more, and followed your suggestion. The Task.Delay statement is back in the code, but it won't be used when ToggleDurationMs is set to 0.

More importantly! I also changed how that Task.Delay statement is used:

The result is that it looks pretty smooth on my computer now, with ToggleDurationMs set to 15ms. (It's even smoother when set to 0, but now it's much harder to see the difference :) )

flyingpie commented 3 years ago

@timmolderez That's actually a really nice addition, I didn't take the time it takes to move the window into account, which is probably what caused the problems on battery-saving systems in the first place. I'll take a closer look at the code soon, though I'm thankful for your work already!

flyingpie commented 3 years ago

@timmolderez Thank you for your contribution, this is gonna be part of the next release (1.2.0) :)