Re: Need informations about NSAnimation on MacOS

[Xavier Glattard]

Fred Kiefer <fredkiefer <at> gmx.de> writes:

> 
> Xavier Glattard wrote:
> >  <leeg <at> thaesofereode.info> writes:
> > 
> >>> 2) I dont understand the 3 NSAnimationCurve...
> >>> - Are they linear or polynomic functions ?
> >>> - what do 'slowly speeds up' and 'slows down' really mean ?
> >>>
> >> They're certainly polynomial, but in fact they may not fit any
> >> finite-order polynomial function (may be sinusoidal for instance).  I
> >> agree with the suggestion by Nicolas that approximating a Bezier curve is
> >> a good approach.
> > 
> > I agree 
> > 
> > I had a quick look in gnustep code but i can't find any Bezier curve
> > implementation : all the math is hidden in the low level display 
> > server/library.
> > 
> > Any suggestion ? A well-known library that could help me ?
> > 
> 
> Not sure, if this Bezier curve isn't a bit over the top. What we need is
> just the ability to map from currentProgress to currentValue both
> between 0.0 and 1.0 (no matter what the documentation says about 0.1).
> So why not just do what Alexander Malmberg did in blit-main.m and
> pre-compute the four mappings for 256 values and map onto them? Or
> perhaps even that is not worthwhile, even when we use pow() this wont be
> to expensive.

What will we do with this class ?

Your idea is fast and simple, but such an animation can not be custumized
(compilation), and a long animation (more than 8-9 sec) might be jerky.
A Bezier 'curve' (that would be actually a 1D bezier curve) needs more
computation, but can be easily customized (initial and final speeds, 'rubber
effect'...), and allows smooth animation for any duration.

And if the user needs some very accurate synchronization (with progressMarks,
ith a sound for example), Bezier curves is the best choice.

The 1D Bezier curve that we would need is not so complicated :
  F(t) = [ 3.u.(1-t)^2 + 3.(1-v).t.(1-t) + t^2 ] . t 
where :
 u = initial 'speed'
 v = final 'speed'

To get a smooth curve switch the operations would be the same with any
mechanism, so that would really slow down the 1st one, but not so the 2nd one.

We may also allow the user to choose what mechanism he wants... (like with
'AnimationMode'). I think of some classes that can be use as a delegate to
compute the 'currentValue'...

Xavier