setInterval does not block user
interaction. I think it will do what you need.
Tracy
Hi Ted
Re: If the player was 20 times faster ...
I'm sure you can build any language feature you need on top of a language that
executed fast enough, but I think it's about more subtle things like the ease
of programming and the elegance you can achieve out of the box ...
Re: "N Threads - Network operations"
I need to have a thread in my yet-to-be-built Flex UI that will constantly poll
a Python server on the user's desktop (thru HTTPService) for screen updates,
while the Flex UI remaining totally responsive to user interaction.
This is instead of having to build server capability into the Flex UI, i.e. to
allow the Python server to push updates to Flex (via binary socket). But then I
also need to send requests to the Python server from the Flex UI (thru
HTTPServicet) on demand (as the user invokes certain functions.)
The point of what I'm trying to do is to allow the Flex UI to be updated in
realtime by the Python server, while being totally responsive to user
interaction, while able to send requests to the Python server on the user's
desktop (on demand synchronous method invocations) and while also being able to
communicate with FES on the remote server.
I'm trying to find out from if it's possible to have a separate
"thread" that does constant polling (of new screen data), i.e.
without interrupting the AS execution thread. This way I won't have to develop
a custom push-pull protocol on top of binary socket (I would rather stick to
HTTPService for simplicity)
But if I can't run a separate thread for polling (via HTTPService) then I would
have to resort to the do it yourself approach and implement a push0pull
protocol on top of binary socket.. which is what I though you had done with
SYNC/Python/Tiwsted ... waiting on when you'll release the source on IFBIN...
I think the VNC example by Darron Schall must be using a custom protocol over
binary socket to push screen data to the client ... If that's the case I would
sign up and check it out ...
Luckily, I get to set my own deadlines ... else I woudl have been pulling my
hair out :)
Thanks
Marc
Ted Patrick
<[EMAIL PROTECTED]> wrote:
> Last I heard the Flash player was single threaded.
> If that's still true, the question of synchronization is moot.
Multiple threads have been in the player for some time now. There are multiple
threads in the flash player as follows:
Single Thread of Execution – AS Execution & DisplayList Rendering
N Threads of Execution – Network operations
These two types of player threads synchronize data by using the event model. In
AVM1, onData, onLoad, onXML were all fired after data has arrived from network
operations into the event processing area of the main execution loop/thread.
I posted a helpful article on the Player Mental Model here:
http://www.powersdk.com/ted/2005/07/flash-player-mental-model-elastic.php
Separate player instances are not limited in parallel code execution. If the
need arise(most time it does not) you can have processing occurring in one
player that runs in parallel to another player instance and communicate across
SWF boundaries with LocalConnection. Loading one SWF file into another does not
produce a separate player instances as the loaded SWF files simply extend the
player they are loaded into. There is one and only one _level0! :)
Flash needs to support both Async and Sync models:
http://www.powersdk.com/ted/2005/11/macromedia-please-add.php
As for threads in AS, I think this would be a mistake. The introduction of race
conditions, blocking, and other techniques would not be ECMA compatible let
alone easy to work with. The current direction of player development will
introduce major leaps in player performance that should remove the need for
threading in the long run.
At Spark Europe the Flash Player team talked a bit about Flash Player 9 and
hardware based GPU rendering. In Player 8.5, graphics rendering is currently
the limiting factor within the player as the performance ceiling on AS3
performance has been massively lifted ( Thanks Gary, Edwin, & Team ). With
hardware based rendering, the CPU based rendering will move to being GPU based
for 2D operations. This will allow the player to internally cycle 20+ times
faster and provide more resource to the ActionScript engine. We are very likely
to see another huge multiple in player performance in Flash Player 9+ atop the
performance gains in Flash Player 8.5.
I think many are missing the fact that FP8.5 is laying the foundation for
dramatic player performance moving forward.
A better question to ask:
If the player was 20 times faster than 8.5, would you still need threads?
Also at these speeds, we would have cycles to waste on Synchonous code. :)
Just remember, Adobe is always listening! Speak up if you want something.
My 2 cents,
Cynergy Systems Corp.
Theodore Patrick
Sr. Consultant
[EMAIL PROTECTED]
tel: 1.866.CYNERGY
http://www.cynergysystems.com
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.2.1/278 - Release Date: 3/9/2006
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Yahoo! Mail
Bring photos to life! New
PhotoMail makes sharing a breeze.
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
YAHOO! GROUPS LINKS
