Alex, Eagerly awaiting news of your progress! — Scott Morrow
Elementary Software (Now with 20% less chalk dust!) web https://elementarysoftware.com/ email sc...@elementarysoftware.com booth 1-800-615-0867 ------------------------------------------------------ > On Jun 30, 2020, at 6:40 PM, Alex Tweedly via use-livecode > <use-livecode@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
