by Alex Harui @ blogs.adobe.com. January 1, 2008
Every once in a while, someone decides they would like to see threading or background processing in Actionscript. While the underlying Flash Player and Operating System use threads, the execution model for Actionscript does not.
For those who don’t know, ‘threading’ is essentially the ability to have the code do something in the background while the UI is doing something else. Because Actionscript is single-threaded, if you spend lots of time doing heavy computation, the UI cannot be updated while you’re doing that computation so your application appears stuck or effects don’t run smoothly.
Similarly, there is no yielding or blocking in Actionscript either. If the next line of code is supposed to run, you cannot prevent the next line of code from running. That means that when you call Alert.show(), the next line of code following that runs right away. In many other runtimes, the Alert window has to be closed before the next line of code continues.
Threading may be a feature of Actionscript some day, but until then, you have to live with the fact that there is no such thing right now.
In other single-threaded environments, you can get something like threads via ‘pseudo-threading’, which involves dividing up the heavy computation into small chunks on your own. (There is no solution to allow for blocking or yielding other than refactoring the application to be even-driven). Pseudo-threading is painful, but doable in most situations. Iterative tasks are easier than recursive ones, the chunk size has to be small enough to not degrade the UI response time and restoration of the execution context must be efficient otherwise you’ll spend too much time saving and restoring your state and not get anything done.
Someone asked me how I would generalize such a thing. I put this together in a couple of hours. It represents my first thoughts, not some deep thinking on the subject. A PseudoThread instance takes a callback function and a context object and calls the callback function with the context object as mahy times as it thinks it can get away with it within the frame interval. The callback function should update the context object before returning and return false when done and the PseudoThread instance dispatches an event and destroys itself.
PseudoThread.as
The following is the a test that loads an image, and adds a red tint to a copy of the image one row at a time. I purposefully slowed it down with trace statements so you can see that it doesn’t do it all at once and doesn’t seem to affect the rotating button.
PseudoThreadTest.swf
These two links are the source file and the test image.
PseudoThreadTest.mxml
the test image
The usual caveats apply (there are probably bugs, limitations, etc). Hope it helps.
Every once in a while, someone decides they would like to see threading or background processing in Actionscript. While the underlying Flash Player and Operating System use threads, the execution model for Actionscript does not.
For those who don’t know, ‘threading’ is essentially the ability to have the code do something in the background while the UI is doing something else. Because Actionscript is single-threaded, if you spend lots of time doing heavy computation, the UI cannot be updated while you’re doing that computation so your application appears stuck or effects don’t run smoothly.
Similarly, there is no yielding or blocking in Actionscript either. If the next line of code is supposed to run, you cannot prevent the next line of code from running. That means that when you call Alert.show(), the next line of code following that runs right away. In many other runtimes, the Alert window has to be closed before the next line of code continues.
Threading may be a feature of Actionscript some day, but until then, you have to live with the fact that there is no such thing right now.
In other single-threaded environments, you can get something like threads via ‘pseudo-threading’, which involves dividing up the heavy computation into small chunks on your own. (There is no solution to allow for blocking or yielding other than refactoring the application to be even-driven). Pseudo-threading is painful, but doable in most situations. Iterative tasks are easier than recursive ones, the chunk size has to be small enough to not degrade the UI response time and restoration of the execution context must be efficient otherwise you’ll spend too much time saving and restoring your state and not get anything done.
Someone asked me how I would generalize such a thing. I put this together in a couple of hours. It represents my first thoughts, not some deep thinking on the subject. A PseudoThread instance takes a callback function and a context object and calls the callback function with the context object as mahy times as it thinks it can get away with it within the frame interval. The callback function should update the context object before returning and return false when done and the PseudoThread instance dispatches an event and destroys itself.
PseudoThread.as
The following is the a test that loads an image, and adds a red tint to a copy of the image one row at a time. I purposefully slowed it down with trace statements so you can see that it doesn’t do it all at once and doesn’t seem to affect the rotating button.
PseudoThreadTest.swf
These two links are the source file and the test image.
PseudoThreadTest.mxml
the test image
The usual caveats apply (there are probably bugs, limitations, etc). Hope it helps.
Comments