Animation Engine: speed tips

[Alex Tweedly]

Hi David,

I had a quick look at this (for slightly selfish reasons - I will be 
doing some simple animation soon, so this piqued my interest to look at 
it sooner :-)

[ all comments on performance or timing here are on an aging (2011) 
Macbook Pro, LC 9.6.0 ]

So, there's good news, and there's bad news :-)

1. Bad news.

It is slow (surprisingly, disappointingly slow) to move graphic objects 
in LC. Moving small simple objects (unfilled circle graphics <20 pixels 
across) over an uncomplicated background. Each move takes between 1 and 
2.6 msecs. (Yes, that's for one object !!)

[ Puts on 'grumpy old man' hat = that's about the same time as it took 
on my old Atari ST - 34 years ago!! Where's Moore's Law when I need it 
:-). ]

2. Good news.

Although disappointing performance, it is (probably) good enough for 
your described example. Around 30 simple, small objects moving, 20 fps 
~= 700ms within a second; it should just be doable.

3. Bad News.

You're on the edge !!  The timings above were for moving objects in a 
simple, tight loop. (see sample code below my sig.)  You have a little 
bit of spare CPU left over to handle overhead, object management, new 
co-ord calculation, etc., but not very much.

Animation Engine.

It's a powerful library - has lots of good stuff to do fading, morphing, 
collision detection, input constraint, color changes, animated scrolls 
(bounce, overshoot, ...), and then it has two methods of just *moving* 
LC controls.

The 'classic' version requires the developer to set up a timer/loop 
handler, and use the various aeMovexxx handlers; because of the timer 
handling it's tricky and needs care from the developer.

The other version is only for straight line moves (aeMoveTo); this is 
much simpler to use, can handle multiple shapes moving in synch and does 
it very efficiently. (The older equivalent was aeMoveLinear, which is 
deprecated). If all your moving is (or can be cast into) using this 
version, you might have no problems. Note Malte describes aeMoveTo as 
'frame-perfect' - all the moves done by aeMoveTo happen perfectly 
aligned by the (single) frame timer, so moves can be precisely 
coordindated to start and/or finish at exactly the same time.

If it can't be, then you might think about adding new functionality to 
AE to provide a similar capability , using the same single timer that 
aeMoveTo uses.

My needs are slightly different:-
1. linear and "hop" moves only (*)
2. need to string together multiple moves within a 'frame-perfect' setting

btw - this 'stringing together' is exactly what you would need for 
hand-drawn curve following; you'd form a points-list from the 
hand-drawing, then construct a series of linear moves along each edge.

I decided the easiest way to achieve what I need was a simple 
purpose-specific library, that has just these features. It's simple to 
use, understand and debug - currently < 200 lines, and likely to finish 
up around 250 lines by the time I'm done adding features.

(*) What's a "hop" move?
Think of a child's board game (Ludo, S&Ladders, ...) When you move a 
piece, you don't (if you're playing with a child) usually just pick it 
up and move it (say) 5 squares, instead you go "...1...2...3...4...5", 
while touching the piece in or near each square in turn. That's a hop 
move (or a series of hop-moves. :-)

Anyway - I have that working now, so with luck I'll get a chance to work 
on it this week and get it tidied up, and release a first version by the 
weekend, so if you (or anyone) is interested they can try it out.

Alex.

Simple benchmark:

I finished up with a pretty trivial example bit of code:


 >    put the loc of grc "g1" into tmp
 >    repeat 100 times
 >       add 1 to item 1 of tmp
 >       set the loc of grc "g1" to tmp
 >       wait 0 with messages
 >    end repeat

Notes:

0. Graphic "g1" is a simple, small circle.

1. if the graphic wanders off screen (out of window) the time taken 
drops to 0.

2. If you remove the "add 1 to item 1 of tmp" (i.e. the graphic remains 
in the same place), then again the time drops to effectively 0.

So with this simple code, I find that (on my aging Macbook Pro), those 
100 moves take between 125 and 275 ms (i.e. just about 1 to 2.5 ms per 
shape to move). And that variation is easily matched against the 
complexity of the surroundings the piece is moving through - if it moves 
over (or under) many other graphic objects, it takes clearly longer.

Good luck.

On 28/06/2020 01:09, David Bovill via use-livecode wrote:

> I made a quick test - creating and animating small graphic circles along a complex curve with many points. It works fine with one or two animated spheres but I’d like to be able to animate >30 and it slows to a crawl after 4 or 5. I tried setting the layer mode appropriately for all the objects - but I’m doing this on a new MacBook Pro - and it does not make a difference.
>
> Does anyone have an example stack with multiple animated objects that I can compare / test for speed?
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode