[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-artists
Subject: Re: [kde-artists] [Back to Basics] Better animation for KWin effects
From: Martin Klapetek <martin.klapetek () gmail ! com>
Date: 2012-10-01 7:39:36
Message-ID: CAPLgePp0SAOq-Ne4K01KNpRL=LJqtBrkQEPTy9mkTzMwxcfOww () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sun, Sep 30, 2012 at 10:52 PM, Aaron J. Seigo <aseigo@kde.org> wrote:
> On Sunday, September 30, 2012 21:50:02 Martin Klapetek wrote:
> > Fwiw, I personally think that the "Fast" is way too fast, for example
> > minimizing the window animation is not really seen as it is so quick. On
>
> animations do not always need to be (noticably) seen to be effective. this
> is,
> in fact, one of the common errors i see with animations in applications:
> the
> developer / designer feels that animations must be noticeable to be
> effective
> (my current pet peeve is "bounce out" effects that overshoot ;).
>
True, they don't have to be always noticably seen, but then what's the
point of the animation in the first place? ;) If you do not notice the
animation, there could just as well be none, which will even save resources
(arguably minimally).
> i've found that for most transition effects (where the effect is simply
> there to
> easy a transition between states but itself conveys no useful information)
> that 250ms is usually "just right", with some larger state changes
> benifitting
> from a slightly longer 330ms. there are some that work better with even
> lower
> times, as long as you can get the framerate up.
>
> my main personal wishes with kwin's effects are:
>
> * consistent, fast timing for all transitional effects; inconsistency gets
> noticed by the eye and makes it feel less "real"
> * keep states between transitions minimal; e.g. fading out when closing
> should
> not go through many steps and should fade quickly (so an OutCubic).
> basically,
> anything where something goes away should go away faster at the begining;
> antyhing where something "comes" should start quickly; this matches a
> person's
> desires quicker so that they aren't "waiting" for the animation (linear
> easing
> curves work in some cases, of course, like the sliding of the
> focus/windows in
> alt tab boxes)
> * transitions everywhere: for instance when moving a window it instantly
> goes
> translucent, a 100ms transition (even though it would only be 1-2 frames)
> would probably add something; another example would be when a window comes
> in
> front of another window via alt-tab, instead of just instantly showing it,
> a
> very fast fade in would be great.
>
All of this^. Especially the transitions.
> > the other hand, "Normal" sometimes really does feel slow-ish. But that
> > depends on each plugin.
>
> > I think we miss maximize effect
>
> +1 ... this makes a huge difference; i played with the one that was
> included
> with the generic animations plugin when it was being developed and the
> difference is immediately noticeable. it removes one of the last bits that
> is
> not consistent.
>
--
Martin Klapetek | KDE Developer
[Attachment #5 (text/html)]
<div>On Sun, Sep 30, 2012 at 10:52 PM, Aaron J. Seigo <span \
dir="ltr"><<a href="mailto:aseigo@kde.org" \
target="_blank">aseigo@kde.org</a>></span> wrote:</div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sunday, September 30, 2012 21:50:02 Martin Klapetek \
wrote:<br> > Fwiw, I personally think that the "Fast" is way \
too fast, for example<br> > minimizing the window animation is not \
really seen as it is so quick. On<br> <br>
</div>animations do not always need to be (noticably) seen to be effective. \
this is,<br> in fact, one of the common errors i see with animations in \
applications: the<br> developer / designer feels that animations must be \
noticeable to be effective<br> (my current pet peeve is "bounce \
out" effects that overshoot \
;).<br></blockquote><div><br></div><div>True, they don't have to be \
always noticably seen, but then what's the point of the animation in \
the first place? ;) If you do not notice the animation, there could just as \
well be none, which will even save resources (arguably minimally).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> i've found that for \
most transition effects (where the effect is simply there to<br> easy a \
transition between states but itself conveys no useful information)<br> \
that 250ms is usually "just right", with some larger state \
changes benifitting<br> from a slightly longer 330ms. there are some that \
work better with even lower<br> times, as long as you can get the framerate \
up.<br> <br>
my main personal wishes with kwin's effects are:<br>
<br>
* consistent, fast timing for all transitional effects; inconsistency \
gets<br> noticed by the eye and makes it feel less "real"<br>
* keep states between transitions minimal; e.g. fading out when closing \
should<br> not go through many steps and should fade quickly (so an \
OutCubic). basically,<br> anything where something goes away should go away \
faster at the begining;<br> antyhing where something "comes" \
should start quickly; this matches a person's<br> desires quicker so \
that they aren't "waiting" for the animation (linear \
easing<br> curves work in some cases, of course, like the sliding of the \
focus/windows in<br> alt tab boxes)<br>
* transitions everywhere: for instance when moving a window it instantly \
goes<br> translucent, a 100ms transition (even though it would only be 1-2 \
frames)<br> would probably add something; another example would be when a \
window comes in<br> front of another window via alt-tab, instead of just \
instantly showing it, a<br> very fast fade in would be \
great.<br></blockquote><div><br></div><div>All of this^. Especially the \
transitions.</div><div> </div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> the other hand, "Normal" sometimes really does feel \
slow-ish. But that<br> > depends on each plugin.<br>
<br>
</div><div class="im">> I think we miss maximize effect<br>
<br>
</div>+1 ... this makes a huge difference; i played with the one that was \
included<br> with the generic animations plugin when it was being developed \
and the<br> difference is immediately noticeable. it removes one of the \
last bits that is<br> not \
consistent.<br></blockquote></div><div><br></div>-- <br><div><span \
style="color:rgb(102,102,102)">Martin Klapetek | KDE \
Developer</span></div><br>
______________________________________________________________________________
kde-artists@kde.org | https://mail.kde.org/mailman/listinfo/kde-artists
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic