Animation Engine: speed tips
alex at tweedly.net
Tue Jun 30 21:40:56 EDT 2020
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.
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*
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
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.
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
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.
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:
More information about the use-livecode