Achieving high performance in Full-HD resolution with ActionScript
I recently had to write a rather simple picture viewing application with a little twist. The image display had to be interesting looking, which means blends, filters and movement. In addition to that the display unit had to run in Full-HD resolution (1920×1080).
Now i don’t know about your system, but with my Core2 Duo E6600 something like that brings the Flash player to it’s knees.
Let me give a little more detail on the project and how i solved the issue.
The display unit was divided into 20 slots (5×4 matrix), each slot is filled with an image. The slots should then blend to new images when instructed to.
This gave me the option to divide the display unit into several processes and distribute them on the two cores of my development machine. I planned to write it so it could also be split up into 4 processes on a quad core machine.
Now the whole deal is, as you might have guessed, dividing the work of the whole system to several processors (or cores). The only problem to solve is to synchronize the separate application instances. And this is where the fun begins.
I planned for two machines, one for the display system and one that hosts the content server and the controlling server. The plan to host the content and the controller on a separate machine constructed because this way you could also work with several machines to feed any number of display units.
I tried to write the system to that when any part would fail (crash), that part could be restarted and the whole system would find into it’s place on it’s own.
Now for the details. The display units are PureMVC based and later compiled to .exe with SWFStudio. For the fun of it, i also wrote the server in ActionScript with SWFStudio. I needed the TCP communication capabilities of SWFStudio, because the Flash Player does not provide listening sockets. Of course the server could have been written in any language.
If you would follow the same path you would sooner or later come across the problem of having multiple listening sockets in an SWFStudio application. You can solve that by constructing multiple listening sockets on the same port (somehow that works in SWFStudio) for as many units as you have. I found that to be a rather strange approach though.
So i wrote it so that there is a primary listening socket that, when connected, will negotiate a new connection with the client. It will then instantiate a new instance of the TCP plugin, open a listening socket, tell the client about it and close the initial socket. This will place the initial socket back in the listening state.
The client will then connect the new, dedicated socket and start request information.
At this point the client will be fed with information like, window size, position, client index, the details of the content server and the indexes for the image slots. It will then place itself at the correct position on screen and begin to load the images from the supplied content server.
I designed the display units to be rather stupid and simple. The protocol over which they are controlled is rather simple. But this came mostly from the fact that the job was rather simple to begin with. Over the protocol you could reset all slots to the initial state or tell a slot to fade to the next image.
The server keeps a map of slot indexes to clients. Now when i want to fade images i could choose between several fade patterns (linear, diagonal, random, row-wise, …). I would then construct an object from the specific fade class. That fade would then fire an event when a slot (or several) should be changed.
In the event it passes an array of slots that should be triggered.
Now the server could simply listen to that event and invoke the fade-to-next command over the socket of the client that contains that slot.
That basically takes care of it all. One must be sure to properly handle all socket events. An abstraction for the sockets provided by SWFStudio is highly recommended. When a client dies the socket has to be freed and once a new client connects it needs it’s slot indexes re-assigned.
All in all, this was a very fun project. It’s just nice to kill parts of a system like that and see everything re-organize itself.
