[PATCH 1/2] animation: zoom: don't start animation with alpha set to 0
From: "Rune K. Svendsen" 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. --- src/animation.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/src/animation.c b/src/animation.c index 9e2ad4e..e86fda3 100644 --- a/src/animation.c +++ b/src/animation.c @@ -214,6 +214,9 @@ zoom_frame(struct weston_surface_animation *animation) 0.5f * es->geometry.height, 0); es->alpha = animation->spring.current; + //starting with alpha set to 0 will cause the first frames to be invisible. + if (es->alpha < 0.3) + es->alpha = 0.3; if (es->alpha > 1.0) es->alpha = 1.0; } -- 1.7.10.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] animation: zoom: don't start animation with alpha set to 0
On Sun, Feb 24, 2013 at 06:43:33AM +0100, Rune K. Svendsen wrote: > From: "Rune K. Svendsen" > > 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 > --- > src/animation.c |3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/animation.c b/src/animation.c > index 9e2ad4e..e86fda3 100644 > --- a/src/animation.c > +++ b/src/animation.c > @@ -214,6 +214,9 @@ zoom_frame(struct weston_surface_animation *animation) > 0.5f * es->geometry.height, 0); > > es->alpha = animation->spring.current; > + //starting with alpha set to 0 will cause the first frames to be > invisible. > + if (es->alpha < 0.3) > + es->alpha = 0.3; > if (es->alpha > 1.0) > es->alpha = 1.0; > } > -- > 1.7.10.4 > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] animation: zoom: don't start animation with alpha set to 0
On Wed, 27 Feb 2013 16:08:30 -0500 Kristian Høgsberg wrote: > On Sun, Feb 24, 2013 at 06:43:33AM +0100, Rune K. Svendsen wrote: > > From: "Rune K. Svendsen" > > > > 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. True. Unfortunately tweaking the animation parameters is hard. I've done it in the past using trial and error, and plotting the spring value curve in gnuplot or octave. My guess is that the existing animation starts with zero velocity and takes too long to accelerate, to finally become visible. Also the compositor fade-in animation runs (unless fixed by now) for a lot longer than what is perceivable. We could probably use some helper tool in the weston repository for visualising the spring action, so it's possible to find good parameters. Simply watching the real animation is not too helpful, it needs to be a graph, IMHO. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] animation: zoom: don't start animation with alpha set to 0
On Wed, Feb 27, 2013 at 10:08 PM, Kristian Høgsberg wrote:
> On Sun, Feb 24, 2013 at 06:43:33AM +0100, Rune K. Svendsen wrote:
> > From: "Rune K. Svendsen"
> >
> > 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.0000.00
0.0120.0058558001
0.0230.0272109155
0.0340.0606714115
0.0440.0882380754
0.0550.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.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
