On Wed, 27 Feb 2013 16:08:30 -0500 Kristian Høgsberg <hoegsb...@gmail.com> wrote:
> On Sun, Feb 24, 2013 at 06:43:33AM +0100, Rune K. Svendsen wrote: > > From: "Rune K. Svendsen" <runesv...@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. 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
