[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