Tweak slidingpopups effect to make animation smoother
Needs ReviewPublic

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


Group Reviewers

Summary of changes so far:

  • Easing function for slide-in changed to OutQuart
  • Easing function for slide-out changed to InQuad (uses OutQuad in code as the animation is reversed)
  • Opacity is now interpolated, too.


  • Discuss and analyse easing curves for various kinds of animations with VDG (possibly updated HIG)

Diff Detail

R108 KWin
Lint OK
No Unit Test Coverage
Build Status
Buildable 16603
Build 16621: arc lint + arc unit
sefaeyeoglu created this revision.Jan 5 2019, 10:27 PM
Restricted Application added a project: KWin. · View Herald TranscriptJan 5 2019, 10:27 PM
Restricted Application added a subscriber: kwin. · View Herald Transcript
sefaeyeoglu requested review of this revision.Jan 5 2019, 10:27 PM
zzag requested changes to this revision.Jan 5 2019, 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.Jan 5 2019, 10:56 PM
zzag added a reviewer: KWin.Jan 5 2019, 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.

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.Jan 6 2019, 3:45 PM

Change opacity for custom slideLengths only

sefaeyeoglu marked an inline comment as done.Jan 6 2019, 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)Jan 6 2019, 4:33 PM
abetts added a subscriber: abetts.Jan 6 2019, 4:39 PM

Do you have a before and after gif or video?

sefaeyeoglu added a comment.EditedJan 6 2019, 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:


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.EditedJan 6 2019, 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.Jan 6 2019, 5:03 PM
sefaeyeoglu added a comment.EditedJan 6 2019, 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.Jan 8 2019, 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.EditedJan 9 2019, 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.


  • 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.

Compomise between old behaviour and my proposal. Now uses fixed slideLength again, but with different easing.

I recently set up a proper working environment again and started tinkering with different easings and slide-lengths. I decided to make a compromise between the old animation and the one I proposed before.

zzag added a comment.Sun, Sep 15, 9:38 PM

So, I've been running your patch for a while and have to admit that disappearing animation looks better. However, I advise you and VDG to analyze (perhaps update hig as well?) our choice of easing curves in default effects, e.g. morphing popups, sliding popups, fade, etc, and based on that pick better curves.


Unrelated change.

Tidy up code

Fix syntax error

sefaeyeoglu retitled this revision from Modernize easing function of slidingpopups effect. to Tweak slidingpopups effect to make animation smoother.Sun, Sep 15, 9:57 PM
sefaeyeoglu edited the summary of this revision. (Show Details)

Fix wrong opacity condition for vertical popups