Modernize easing function of slidingpopups effect.
Needs RevisionPublic

Authored by sefaeyeoglu on Sat, Jan 5, 10:27 PM.

Details

Reviewers
zzag
Group Reviewers
VDG
KWin
Summary

Easing functions changed to OutExpo.
Slide-length now 100% of the popup width/height by default.
Opacity now interpolated, too

Diff Detail

Repository
R108 KWin
Branch
sliding-popup-easing (branched from master)
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 6704
Build 6722: arc lint + arc unit
sefaeyeoglu created this revision.Sat, Jan 5, 10:27 PM
Restricted Application added a project: KWin. · View Herald TranscriptSat, Jan 5, 10:27 PM
Restricted Application added a subscriber: kwin. · View Herald Transcript
sefaeyeoglu requested review of this revision.Sat, Jan 5, 10:27 PM
zzag requested changes to this revision.Sat, Jan 5, 10:56 PM
zzag added a subscriber: zzag.

It's wrong to ignore slideLength. One can specify how much to slide.

Also, what's wrong with inoutsine?

This revision now requires changes to proceed.Sat, Jan 5, 10:56 PM
zzag added a reviewer: KWin.Sat, Jan 5, 10:57 PM

I personally feel, that timing functions for things appearing should not accelerate, but rather only decelerate.
I am often designing things with influences from different design guidelines, but when it comes to animation I often look at the Material Design Guidelines, as I think that Material Design animations feel natural. They have a section about things appearing and disappearing here. Therefore I chose decelerating/accelerating timing functions.

I probably was too fast with removing slideLength, as I didn't notice, it could be specified. My main point was, that slideLength should not be the same for all windows, as larger windows should also travel longer distances in my opinion.

I will add it back for the option to specify it, but will leave it at 100% of the window height/width by default.

Restore support for custom slideLength

davidedmundson added inline comments.
effects/slidingpopups/slidingpopups.cpp
130

Have you tested this with the autohide panel. I doubt it will look good.

We want that for newly appearing windows in the middle of the screen, but not for a window that clearly comes in from offscreen.
The current heuristic of basing that off slideLength seems to work.

sefaeyeoglu updated this revision to Diff 48803.Sun, Jan 6, 3:45 PM

Change opacity for custom slideLengths only

sefaeyeoglu marked an inline comment as done.Sun, Jan 6, 3:47 PM

I just added the if statement back (but keeping the interpolate). It actually looks better now!

sefaeyeoglu edited the summary of this revision. (Show Details)Sun, Jan 6, 4:33 PM
abetts added a subscriber: abetts.Sun, Jan 6, 4:39 PM

Do you have a before and after gif or video?

sefaeyeoglu added a comment.EditedSun, Jan 6, 4:41 PM

Do you have a before and after gif or video?

Not right now, I am not at home at the moment. I can provide a before/after gif later.

Unrelated to your comment:

effects/slidingpopups/slidingpopups.cpp
453

The comment here needs to be changed. It says InQuart, as I was experimenting with different easing functions before settling on OutExpo.

zzag requested changes to this revision.EditedSun, Jan 6, 5:03 PM

I tested this patch. In general, it doesn't feel consistent with other animations, imho. I suggest to open a new task regarding easing curves before actually changing them.

This revision now requires changes to proceed.Sun, Jan 6, 5:03 PM
sefaeyeoglu added a comment.EditedSun, Jan 6, 5:14 PM
In D18000#387618, @zzag wrote:

I tested this patch. In general, it doesn't feel consistent with other animations. I suggest to open a new task regarding easing curves before actually changing them.

It is true, that it may be inconsistent with other animations, as it a quicker (longer distance in the same time) animation in comparison.
I was looking around in the Human Interface Guidelines and didn't find a section about motion. We could create a meta task, which covers motion in Plasma in general. In my opinion most animations in Plasma feel a bit old (I am probably used to faster animations mainly from the Material Design Guidelines).

I looked into this here, as this was the first animation I wanted to change.

I really like most animations in Android (Pie) as they feel modern and polished. I may experiment with AOSP-like animations in the future.

Do you have a before and after gif or video?

Here you go. It is only 30fps and very small.

The first two are with the old animation. the last three are with the new animation. As I am running on the proprietary nvidia driver it may look choppy, but it runs smooth on my laptop with Intel graphics.

ngraham added a subscriber: ngraham.Tue, Jan 8, 1:31 AM

Looks better or at least fine to me. No visual objection.

I don't really think that it looks that different than other animations. If one gets used to it it isn't that strange anymore.

zzag added a comment.EditedWed, Jan 9, 11:55 AM

The main problem I see is that it's too rapid, imho. It's not very pleasant to watch how some entity moves too rapidly.

I'd like to see some analysis of what's wrong with the current choice of easing curves, how it can be fixed, and why we picked this easing curve instead of that, so we have a "bigger picture" of what should be done.

I can only speak from experience. I don't know if there are any scientific studies that look at user experience with a focus of animation.

So this is my own opinion:

Animations should be quick and clear. An object should animate in a clearly comprehensible way. That means that an object should not appear out of nowhere. It should rather come from a place the user can't see. As we have four screen borders we could just let the object translate from a screen edge, similar to how one would open a drawer in the real world. Of course this is similar to the Material Design Guidelines as this is about comparing design to the real world. Now to this example:
Let's say we have an application launcher menu in the bottom left of the screen. When I click it I expect it to come out of the lower screen edge on the left. Now thinking in the real world: When I open a drawer it does not fade in and only travel a specific short distance. I can see it open from 0% open to 100% open without any jump. Therefore the application launcher should act like a real drawer. Now let's talk about the timing of the animation. I don't open a drawer in just 150ms like in the slidingpopups effect. These 150ms may be tweaked to a bit longer, while staying snappy. There is a range of time where an animation has the perfect length. But that depends on the distance and easing and should be further investigated.

TL;DR

  • Animations should resemble their real world counterpaths (e.g. Sliding Popups -> Opening a drawer in the real world)
  • Timing should be investigated
  • Timing depends on distance and easing.