[PATCH 1/2] animation: zoom: don't start animation with alpha set to 0

[Rune Kjær Svendsen]

On Wed, Feb 27, 2013 at 10:08 PM, Kristian Høgsberg <hoegsberg at gmail.com>wrote:

> On Sun, Feb 24, 2013 at 06:43:33AM +0100, Rune K. Svendsen wrote:
> > From: "Rune K. Svendsen" <runesvend at gmail.com>
> >
> > I was doing some research on why I thought enabling the zoom/fade
> > animations added latency (a gap between releasing the launcher
> > button and the window appearing), and I found out that it's because,
> > for the first few frames, the alpha value is set to zero due to the
> > spring value being zero for the first few frames. This effectively
> > causes the first few frames to be invisible, and so, delays the
> > animation by about 20-30 ms. Making sure the alpha value has a
> > minimum value to begin with, makes opening new windows feel more
> > responsive when the animation is enabled.
>
> I'm not sure about these two.  I think we should try to tweak the
> animation to be faster instead.  Starting at 0.3 alpha feels a little
> bit like it pops into view and then fades the rest of the way to 1.0.
>
> Kristian


Yeah you have a point. I recall that 0.3 was the first value it jumped to
that was greater than 0.01, but now that I run it again, this isn't the
case. I'm not sure what I did differently back then or if I made a mistake.

In any case, the point I'm trying to make, is that starting an animation
with a transparent frame is sort of like the graphics programmer's "off by
one" error. What I mean is that when fading in something from transparent
to opaque, it doesn't make sense to start the first frame with a completely
transparent object, since this will just be the equivalent of not having
started the animation in the first place. The animation will only have
appeared to start when the object is of sufficient opacity to be visible.

I've plotted the values I get from just printing the value
of animation->spring.current in zoom_frame (in animation.c).

https://docs.google.com/spreadsheet/ccc?key=0AhfpSow9S9ZMdEs1YmVOQkNCNC1BRmtFbzVyWV9OclE&usp=sharing

The beginning of the animation looks like this:

time     value
0.000    0.0000000000
0.012    0.0058558001
0.023    0.0272109155
0.034    0.0606714115
0.044    0.0882380754
0.055    0.1355686337

So the first frame isn't visible, the next frame is at 0.6% opacity, then
2.7%, 6%, 8.8%, 13.5%.

I think both the minimum alpha value I chose (0.3) and the way I did it
("snapping" to the minimum value) are wrong. A more sensible minimum value
would be 0.03 (which it reaches 23 ms into the animation). But the real
clean way to do it would be to completely skip the first zero-value.

I think the fundamental issue is that we use the same spring for motion and
transparency. Motion *should* begin from 0 (start) and end at the specified
end value, but doing the same for transparency makes us lose the first
frame.

Also, looking a bit further into why I felt the animation was sluggish, I
found out it takes 120 ms from pressing the launcher button to the
animation starting, so this might actually be the reason I perceive a slow
response, rather than the animation being slow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130302/d3d2967c/attachment.html>