« Merapi Update | Main | Degrafa Auto Shaped »
Green Threading, Psuedo Threads, or AIR as a server?
| By Rich Tretola | January 19, 2009 | |
| 11,939 views |
I have been working on my proposed session for 360|Flex Indianapolis and have been investigating several ways to allow the main worker AIR application to remain responsive to the user while under heavy processing load. The application is built to record short 10 second video clips triggered by a motion sensor at which point it then needs to render the raw data to FLV format. The issue has been that while the FLV is being rendered the application will become unresponsive to the user. There are several possible workarounds to this problem including the use of Green Threading, Psuedo Threads, or my personal proposed solution of offloading the work to a second standalone AIR server application through a LocalConnection call. During my initial tests, this is feasible as the FLV does get rendered.
However, even though LocalConnection calls are asynchronous and each AIR application is supposed to run under its own unique OS process, I am still seeing application free ups of not only my client app and server app but also any other AIR application that is opened at the time (in my case TweetDeck). I have been in communication with the AIR team to try to get a better understanding of what is occurring and will share my findings when I have them.
My plan is to try all three of these methods and report on which worked out the best for me as part of my presentation. Although these concepts are not listed as part of my presentation description, they will be covered. To register for 360|Flex you can visit http://360flex.eventbrite.com/.
Topics: 360Flex, ActionScript 3, Adobe AIR | 4 Comments »
January 20th, 2009 at 11:43 pm
This the topic? http://360flex.uservoice.com/pages/general/suggestions/104726-building-an-air-video-recording-spy-camera-with-motion-detec I’ve voted for this, quite interested in your outcome on this as I’m working with a application that has some heavy computations running for a moment and the UI gets the “Not Responding” message. Using the psuedo threading at the moment.
peas
DK
Reply to this comment
January 22nd, 2009 at 8:44 am
That’s a lot of effort to get around a pretty big issue with AIR that separates it from real desktop toolkits. Hopefully we’ll see something to address this in the future because AIR still has the advantage of building beautiful apps that the other toolkits lack.
In AIR, I went through great lengths to scan a directory of images, recrop them, apply some image mask styling, etc…While I eventually got it working OK through event-chaining, the code was way more cumbersome than working with either .NET Callback threading or Java threading environments.
Would Merapi be able to facilitate your use-case (I heard a rumor they’re supporting callbacks/responders now), or are you just doing something experimental to show another way of working around it?
Reply to this comment
Rich Tretola Reply:
January 22nd, 2009 at 10:05 am
Yes, Merapi would be a possible solution and I have worked with Merapi in the past. Unfortunately, you can not start Merapi from an AIR application.
Reply to this comment
January 22nd, 2009 at 8:59 am
I should add that I had a client build their own AIR-like functionality for an application that only ran on Windows. They embedded IE in a .NET application and ran all their application modules, which were SWF files that communicated with an embedded Python webserver for communicating to the file system. It’s similar to what Merapi does, but this pre-dates AIR by a couple of years.
I’m thinking for a software development house wanting to leverage the beauty of Flex or UI screens, but building high-level custom apps might be able to cobble up something like this without much difficulty. You don’t get the all the AIR, but you most likely don’t need all the AIR APIs, and you get better control of the install. The only thing I haven’t looked into is on OS X what would be required to embed WebKit in a native OSX runtime. The lightweight Python server should be able to be mostly cross-platform.
Again, I’d stress this is for a software development house willing and who has the technical knowledge to pull this off, as opposed to a standard Web 2.0 company that wants to build a useful AIR application in the matter of a few weeks to integrate into existing services.
(Writing about this is on a list of things I’m supposed to do in the next 6 months.)
Anyway, I’ll be anxiously watching your experiments as I’m always looking for new ways to push the platform.
Reply to this comment