Asynchronous control of many objects
jhurley at infostations.com
Thu May 13 08:42:46 CDT 2004
Date: Wed, 12 May 2004 22:24:02 -0700
From: Scott Rossi <scott at tactilemedia.com>
Subject: Re: Asynchronous control of many objects
To: How to use Revolution <use-revolution at lists.runrev.com>
Message-ID: <BCC85482.DAEF%scott at tactilemedia.com>
Content-Type: text/plain; charset="US-ASCII"
Recently, "Jim Hurley" wrote:
> I have a question about asynchronous movement of a large number of
> graphic objects.
> For example, consider a window with 50 graphic objects, perhaps 50
> small spheres--balls.
> I want to have all these objects moving asynchronously. The stack in
> which this comes up can be seen by running the following in the
> message box:
> go url "http://home.infostations.net/jhurley/MultipleBalls.rev"
> My problem is that I use the *identical handler* in *each* of the 50
> balls. That seems inefficient. Is there a way to control a large
> number of objects asynchronously without duplicating the handler in
> each of the objects?
>There are many ways. Here's one (type the following in your message box):
> go url "http://www.tactilemedia.com/download/overkill.rev"
>See the card script for details.
>FWIW, in my experience, I've found that:
>1) Enabling each object to track its own position via its own code requires
>much heavier processor use than using one master script to move everything
>simultaneously. I've locked up several Windows systems doing what you
>describe above, crashing Rev. YMMV.
>2) Interestingly, locking the screen between each call to position multiple
>objects can also place a high demand on the processor; removing the lock
>screen is surprisingly less demanding and, if your objects are small enough,
>you won't notice much delay if any between the move of the first and last
>3) Look at balancing the frequency of the message used to move the objects
>versus the actual distance moved. Sometimes you can employ longer interval
>between moves with a longer distance moved to cut down on processor use, but
>too long a distance may produce jittery, unacceptable results.
>Depending on the size/type of objects, you may not be happy with performance
>beyond about 30 to 40 objects or so. The above demo does indeed use 50
>objects and seems to perform acceptably on Mac OSX, but also appears to near
>max out the processor. Watch out for this on Windows (on my systems, Macs
>seem to be more forgiving). Again, YMMV.
>Tactile Media, Development & Design
Thank you for the example and the analysis. It was a revelation! I
had no idea that it was possible to sequentially move so many objects
without it appearing that they were moving in sequence. It was for
that reason that I gave each object its own code. That was probably
naive since the processor must, in some sense, act sequentially on
I tried locking and unlocking the screen at the beginning and end of
the repeat loop without noticeable effect. After the speed
constraints of HC, I continue to be amazed at how quick RR is.
More information about the use-livecode