So over the long weekend I spent some more time plugging away on the PSP version of my portfolio site. And despite my best efforts I have stumbled on an issue that continues to upset the PSP version of the flash playerï¿½s limited memory.
First a little background to the site. The first version of the site was a journey into a completely code generated flash movie. That is to say, every possible aspect would be generated using ActionScript 2. The rational being to learn some more about the Draw API and also get clarify the ideas of OOP and MVC that i had heard so much about all over the web, but had yet to apply to flash properly. That first development has also offered a great focus for development in terms of learning Flash 8 and more recently both Flash 9 or Action Script 3 and now this latest version for the PSP version of the flash player.
So with the exception of the loaded Bitmap Images and the XML obviously, the rest of the production is all code. In addition this whole experiment has given me some great learning experiences in Eclipse, mtasc, and ant and the whole OpenSource Flash Development.
In my previous post on flash development for PSP I highlighted the need to be very careful with the amount of animation and data being thrown around in the flash player and the need to monitor specifically the memory usage. This is something I have been keeping in mind as I built up the code for the PSP version of my development here:
First I have the base BittubeClass that contains the mtasc main entry point and an application level control class. This handles loading XML, Images and also the creation of Interface Classes. Then I have the various interface elements split into four classes, Loader, NavBar, NavItem, and ContentArea.
Between these classes I am also using some of the mx core classes, or versions of them. These include.
mx.xpath.XPathAPI; (modified to work in mtasc)
mx.utils.Delegate; (modified to work in mtasc)
MovieClipLoader (based on MovieClipLoader6)
The base output from mtasc of the project is a swf that is about 14k in size. Which I am pretty pleased with. I did wonder if generating all the visual assets being created via code was as efficient as using the flash IDE to create the assets. So with this question in mind I produced the following test code:
[as]//generate and display 4 sqaures
var drawSolidRectangle = function(mc_target:MovieClip, str_clipName:String, int_depth:Number, int_w:Number, int_h:Number, int_fillC:Number, int_lineC:Number, int_lineW:Number):MovieClip
var mc_retClip:MovieClip = mc_target.createEmptyMovieClip(str_clipName, int_depth);
if(int_lineW != undefined && int_lineC != undefined)mc_retClip.lineStyle(int_lineW, int_lineC);
_drwRct(mc_retClip, 0, 0, int_w, int_h);
var _drwRct = function(mc_clip:MovieClip, int_x1:Number, int_y1:Number, int_x2:Number, int_y2:Number):Void
mc_clip.moveTo (int_x1, int_y1);
mc_clip.lineTo (int_x2, int_y1);
mc_clip.lineTo (int_x2, int_y2);
mc_clip.lineTo (int_x1, int_y2);
mc_clip.lineTo (int_x1, int_y1);
drawSolidRectangle(_root, “square0_mc”, 0, 100, 100, 0xff0000);
drawSolidRectangle(_root, “square1_mc”, 1, 100, 100, 0xff0000);
drawSolidRectangle(_root, “square2_mc”, 2, 100, 100, 0xff0000);
drawSolidRectangle(_root, “square3_mc”, 3, 100, 100, 0xff0000);[/as]
This results in a file that is 972Bytes in size.
However by simply having a square symbol in the flash library, and placing it on the stage 4 times, and then providing the same instance names as are used in the code above, the swf output is a file of 183Bytes in size. So a smaller initial file in comparison to the code generated assets.
Both movies were exported as Flash 6, using ActionScript2. All other settings were identical.
Further on from this I monitored the memory usage of both movies in task manager. The code generated movie actually appeared to use slightly less memory than the IDE generated movie (6,964K as opposed to the IDE created movie which used 6,988K). So in this particular test Code generated assets actually made a lower impact in memory usage, something, I confess, suprised me.
Returning to the larger development I donï¿½t know if the findings above scale into a more complex project, I would assume that as the code generation continues there would be a point where it will become more efficient to reuse existing IDE based assets than storing dynamically generated assets in memory. I have yet to find time to run an experiment in this way.
Through testing my existing file on the in the PSP flash player I discovered however that my movie still eventually toppled the memory barrier. The initial load of my movie is quite modest. The SWF is 14K compressed The 2 images I load are about 15K in total. The XML Document for the navigation is 285 bytes, the XML documents for the 3 areas are 81K in total. This all gives a total file space requirement of around 115K rounded up to the nearest 5K. This is well within the memory constraints of the 1.5Mb available on the PSP. Yet eventually after clicking through the movie a few times I see the “Out Of Memory” message.
I have checked the movie on the flash 8 player on my windows box. The initial Load of the movie reports 8,576K of memory usage, although as previously explained part of this is the actual stand alone player, not the movie it loads. Once I start navigating the movie, each interaction with the navigation adds between 4-12K to the memory usage. This seems to occur BEFORE anything else happens, i.e. it is a direct result any of the onPress, onRollover or onRollOut events being dispatched, and the generated clip that constitutes the NavItem that is being interacted with having its colour changed. In addition that memory never seems to be released?
Of course this is only the Windows Player, and of course it is a different version. But as I continue to work on this experiment I can safely say this form of memory leak is certainly not an isolated case. I have witnessed my 100K flash movie continue to consume many megabytes of memory once i began to load the XML data. Yet at no point does the memory get released. If there is anything close to this level of leakage within the PSP version of the player I fear that any serious development may well be impossible at the moment on this device.
My next development track will be to explore returning to more OldSkoolFlash development and construction methods, relying less on the dynamic scripting I tend to use today. Bring back, the invisible button, jump movie, and any number of other flash techniques either I developed or help others develop almost 10 years ago.