Animation Engine: speed tips

[J. Landman Gay]

Did you use acceleratedRendering? Set it to true and set the layermode of 
each moving object to dynamic. I'd be curious to see if there's a difference.

--
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On June 30, 2020 8:43:25 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
>
> _______________________________________________
> 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