Animation Engine: speed tips

Wed Jul 1 00:26:17 EDT 2020

Alex,

Eagerly awaiting news of your progress!
—
Scott Morrow

Elementary Software
(Now with 20% less chalk dust!)
web       https://elementarysoftware.com/
email     scott at elementarysoftware.com
booth    1-800-615-0867
------------------------------------------------------

> On Jun 30, 2020, at 6:40 PM, Alex Tweedly via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> 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