as for onenterframe (as with other 'major' events), I usually bubble that
event, as to give me more control of which object(usually a movieclip)
listens and which one doesn't, without altering the object itself. Has
little to do with threading, but I'm not sure if simulating threading in
actionscript actually gives any advantage, performance wise..

On 12/8/05, David Rorex <[EMAIL PROTECTED]> wrote:
>
> You can always write some kind of wrapper, so you don't have to mess
> around with empty
> movieclips, and onEnterFrame, etc.
>
> function caluculateStuff()
> {
>    // set up any data needed for calculation
>    // ...
>
>    TaskManager.forloop(loopFunction, 1, 10, finalFunction);
>
>    function loopFunction(var i:Number)
>    {
>         trace("calculating number: "+i); //traces out 1 thru 10
>    }
>
>    function finalFunction()
>    {
>         trace("calculation complete!");
>    }
> }
>
>
> Then internally in TaskManager, you only run 1 loop per frame, or you
> could use getTimer() to measure how long it is taking, and do as many
> per frame as you can, without slowing things down too much. It's
> slightly more typing than a simple for loop, but it's not that bad.
>
> I'll leave the implementation of TaskManager as an exercise for the reader
> :)
>
> -David R
>
> On 12/7/05, Chris Allen <[EMAIL PROTECTED]> wrote:
> > Hahaha,
> >
> > Okay your point is well taken.  Especially since I am currently working
> on
> > fixing a multi-threaded Java socket application at the moment.
> > Multi-threaded programing isn't a walk in the park, that's for
> sure.  But,
> > with that said, depending on how Scott implements his MovieClip approach
> it
> > might be a lot cleaner than doing onEnterFrame() all over the place.  It
> > certainly sounds like a legitimate approach to me.
> >
> > -Chris
> >
> > On 12/7/05, A.Cicak <[EMAIL PROTECTED]> wrote:
> > >
> > > Believe me multithreding is lot harder to debug, read and maintain in
> most
> > > cases assuming that onEnterFrame is not made
> > > in way that you put 20 loops all in one function (onEnterFrame) . You
> > > could
> > > make object (MultiLoop) which has method Update, some private
> counters,
> > > etc.
> > > and for each problematic loop you just make object MultiLoop, define
> its
> > > Update method, add it to array, and in on enter frame loop through
> that
> > > array and for each element call Update. In this way you could even do
> > > stuff
> > > like set priority to each loop, and for example call update in each
> pass
> > > same number of times as is MultiLoop.Priority value. Code to process
> all
> > > loops including priority support wouldnt be longer that 10-15 lines of
> > > code,
> > > and thats only thing you put in onEnterFrame. Although in real world
> > > program
> > > should be designed so there are not too much "problematic loops"
> anyway.
> > >
> > >
> > > "Chris Allen" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]
> > > On 12/7/05, A.Cicak <[EMAIL PROTECTED]> wrote:
> > > > I dont understand how your UI could lock in the first place? Sockets
> and
> > > > sounds are already working in another thread and all other code
> which
> > > > could
> > > > lock the UI (like some long loops, etc.) can be made by "emulating"
> loop
> > > > with onEnterFrame and few
> > > > counters.
> > >
> > > Yeah, but onEnterFrame and counters make for some pretty nasty code
> > > that is hard to read, debug, maintain, etc...
> > >
> > > >
> > > > "Scott Hyndman" <[EMAIL PROTECTED]> wrote in message
> > > > news:[EMAIL PROTECTED]
> > > > Windows 3.1 was single threaded. As I understand it, programs would
> hook
> > > > into the event loop and be given a handle. While they held the
> handle,
> > > > they could run their own code, but they were supposed to release it
> when
> > > > they were finished to allow other running programs to use it.
> > > >
> > > > I guess what I'm trying to say is quite a bit you can do without
> > > > multiple threads.
> > > >
> > > > And just as a side note, I came up with an interesting idea today on
> how
> > > > to emulate multiple threads in Flash. Just use more than one movie!
> Talk
> > > > between the UI movie and the background worker movie with a
> > > > LocalConnection object, and you're in business. No more UI lock.
> > > >
> > > > Scott
> > > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED] On Behalf Of Boon
> > > > Chew
> > > > Sent: December 3, 2005 8:24 PM
> > > > To: Flashcoders mailing list
> > > > Subject: [Flashcoders] Flash is a single-threaded app? Maybe it's
> just
> > > > theAVM? or...
> > > >
> > > >
> > > >   I have read in this  forum that someone loosely coined the phrase
> > > > "Flash is a single thread  app", it's hard to imagine something as
> high
> > > > performance and intricate  as Flash to be a single-threaded app.
> > > >
> > > >   So I started to take the above statement to mean that the
> Actionscript
> > > > VM executes all the code in a sequential fashion but that Flash
> player
> > > > itself is multithreaded, is that a right assumption?
> > > >
> > > >   And what about code that are asynchronous in nature, such as sound
> > > > playing ( new Sound(), onSoundComplete), server-side call  return
> (such
> > > > as LoadVars, XML.onLoad)?  Are these all happening in the single
> thread
> > > > of code execution?
> > > >
> > > >   Looks like a book on Flash and AVM Internal would be nice. :)
> > > >
> > > >   - boon
> > > >
> > > >
> > > >
> > > > ---------------------------------
> > > >  Yahoo! Personals
> > > >  Single? There's someone we'd like you to meet.
> > > >  Lots of someones, actually. Try Yahoo! Personals
> > > > _______________________________________________
> > > > Flashcoders mailing list
> > > > [email protected]
> > > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > > > _______________________________________________
> > > > Flashcoders mailing list
> > > > [email protected]
> > > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Flashcoders mailing list
> > > > [email protected]
> > > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > > >
> > > _______________________________________________
> > > Flashcoders mailing list
> > > [email protected]
> > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > >
> > >
> > >
> > > _______________________________________________
> > > Flashcoders mailing list
> > > [email protected]
> > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > >
> > _______________________________________________
> > Flashcoders mailing list
> > [email protected]
> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >
> _______________________________________________
> Flashcoders mailing list
> [email protected]
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Reply via email to