qt: Reduce overlay animation to 250ms #146

A faster transition will be perceived better from a UX perspective.

Yeah. Why not. Does one feel 50ms difference?

People are used to snappy transitions. It could be compared to speeding up the "Genie Effect" in macOS. Not a performance increase - but a perceived speed increase none the less.

I don't see a reason to change this, there's no guarantees of animation smoothness, it can be worse on slower systems (by missing key frames).

@promag valid point. Can we also consider that since we have been dropping support for older OSs/Libs/Etc. That users will be using better machines?

PS - This level of scrutiny of the Gui is great and what is needed overall! Human Interaction Design is very nuanced! :)

https://xd.adobe.com/ideas/principles/human-computer-interaction/what-is-interaction-design/

That users will be using better machines?

Can't say, but Qt animations over Qt Widgets are doomed to have inconsistent smoothness, because the animation is advanced on the main loop, between paints, input handling and worst locks (this is a real issue at the moment). So even a good machine can show bad animations.

This is not to say I'm agains this, maybe just reword commit to follow an existing convention. Personally I'd write "qt: Reduce overlay animation to 250ms"

I'm concept 0.

In the light of the transition to QML, I'd leave it as is.

From the point of UX, I'd like to see some designer opinions. cc @Bosch-0 @GBKS

Concept ~0 from me.

I don't know about others, but I get very picky with animations, to the point of using custom cubic-bezier easing and tweaking them to around 50ms units, as well as layering and chaining animations. Not sure what the options here are, but making animations smoother can oftentimes be achieved by waiting a few milliseconds until all other activities are finished so the computer doesn't have to do too much at once.

For small elements, I'd suggest shorter animations (link color, for example, is good at 100ms, otherwise it feels unresponsive). For larger elements, 350-600ms can be appropriate (my starting point is typically 400ms). The balance is that users understand what just happened, but don't have enough time to consciously think about it as that's when it distracts you from your current task.

There are also various tricks. For example, sometimes it's enough to render the last 5-10% of an animation. With the right timing, your eye gets tricked into thinking that it saw a much longer motion. That's particularly helpful for things that fade in/out and move at the same time. For the same effect, you can cut the movement and time a lot, which can be less CPU-heavy. Or when you want various elements to fade in and they are on a solid background. Sometimes performance is better when you overlay a rectangle with the background color and fade that out, as you reduce transparency calculations to a single element.

What exactly is appropriate here depends on the details of the animation and the rendering process. I find that it requires looking at it over and over and making tweaks until it "looks right" (yes, I know, not scientific, but this is a human perception thing). Overall, if the performance is not there, I'd mostly avoid animations.

@GBKS

I don't know about others, but I get very picky with animations, to the point of using custom cubic-bezier easing and tweaking them to around 50ms units, as well as layering and chaining animations. Not sure what the options here are, but making animations smoother can oftentimes be achieved by waiting a few milliseconds until all other activities are finished so the computer doesn't have to do too much at once.

In https://github.com/hebasto/gui/commits/201226-bezier I've implemented @GBKS' suggestion

Looks and feels great!

Also I've temporary added the new -duration command line option to allow reviewers and designers to play with different values of the animation duration.

I suggest to vote with a duration range, and I hope the suggested ranges will have a common value :)

For designers (who struggles to build from source) I've made gitian builds for macOS and Windows: https://drive.google.com/drive/folders/1eXOUuMubvna2-gC9dLbQItXxSAqKnx8G?usp=sharing

95eed4c0986bc78419c7e15d2448a5dfdca5828179d92de4e19ddb9b2655af3c  bitcoin-8d90aa937fcc-win64.zip
f87635751aabe49528713c48cb54827a3e292020f254a64337467c445bcf1ca5  bitcoin-8d90aa937fcc-osx-unsigned.dmg

For playing run with a clear datadir:

$ bitcoin-qt -regtest -duration=314

or make the following bitcoin.conf

$ cat bitcoin.conf
regtest=1
duration=314

For initiating the animation back and forth just keep clicking that widget:

Concept ACK, no strong opinion.

Comparing Master and 5b78befcdb8f79b422a9b8fac7e0ab0462d0f049, I can see a slight difference. I had both a master and 5b78befcdb8f79b422a9b8fac7e0ab0462d0f049 qt window open, and I had to closely watch both to notice the difference.

I tested out @hebasto implementation of the cubic bezier animation: https://github.com/hebasto/gui/commits/201226-bezier. I prefer this animation style to the one currently used, it would be nice to get more eyes on this from the designer community in order to fine tune the duration. I personally liked -duration 350.

As other's have mentioned, this might not be worth the effort until we move to a QML based GUI.