FlashPlayer 10 and loading AVM1 content

November 20th, 2008 • 2 comments ActionScript, AIR, Flash
Tags: AIR, AS3, Flash

I’m using some swf assets directly exported from Illustrator CS3. You can export Flash 9 swfs, but as you can’t add any code there you will always get AVM1 content (AS2.0). So it’s basically just an information in the header and maybe Adobe will put an option in the export-settings to actually publish AVM2 swfs. I haven’t tried CS4 so far, maybe it’s in there already?!
Anyway, loading this swfs and moving it to another part of the displayList didn’t cause any problems using FlashPlayer 9. In FlashPlayer 10 I get the runtime error 2180:

Error #2180: It is illegal to move AVM1 content (AS1 or AS2) to a different part of the displayList when it has been loaded into AVM2 (AS3) content.

There are a few options to avoid this error:

• Don’t load AVM1 content respectively create the assets in Flash to get AVM2 swfs
• Don’t move the assets in a different part of the displayList
• Change the SWF header on-the-fly

The last solution seemed to be perfect and remembering the AVM2Loader class someone created in the upcoming AS3 times it was the easiest solution without changing the workflow. Even if the author Fladdict removed the class, you can still find it on the internet at Troy Gardners blog.

Update 20.11.2008

To use this workaround in an AIR application you have to set allowLoadBytesCodeExecution = true in your LoaderContext otherwise you aren’t allowed to load the bytes of the swf.

...
var loader:Loader = new AVM2Loader();
var loaderContext:LoaderContext = new LoaderContext();
loaderContext.allowLoadBytesCodeExecution = true;
loader.load("file.swf", loaderContext);
...

I’m using some swf assets directly exported from Illustrator CS3. You can export Flash 9 swfs, but as you can’t add any code there you will always get AVM1 content...

FileReference upload II

November 13th, 2008 • 1 comment ActionScript, Flash
Tags: AS3, FileReference, Flash

A few weeks ago I posted about some issues with the FileReference Events in combination with Anti-Virus Tools. Apparently there is another problem even without using such tools. If your upload bandwidth is very low, lets say less than 100 kbit/s or even worse if you are using a good old modem (56kbit/s) to connect to the internet, you might get into trouble handling the IOErrorEvent.IO_ERROR Event. You will get #2038 FIleIOErrors during an upload process on slow connections even though your upload is fine and the file is hitting the server correctly. Actually there is a correlation between the connection speed an the file size.
The bigger the files (>500KB) and the slower the connection the more often you’ll get an IOError.

I think even in AS3 times it’s sometimes better to reclaim good old AS1/AS2 times where error handling didn’t play a major role and just don’t listen to every error event that could occur.

A few weeks ago I posted about some issues with the FileReference Events in combination with Anti-Virus Tools. Apparently there is another problem even without using such tools. If your...

FileReference upload & Anti-Virus Software

October 21st, 2008 • 3 comments ActionScript, Flash
Tags: AS3, FileReference, Flash

Lately I experienced some problems with FileReference upload while using Kapersky Anti-Virus Software. The software has a feature to scan HTTP traffic for viruses which btw. is enabled by default. It uses some kind of cache which forces FileReference Events to be inaccurately or not beeing dispatched at all. As there are even more Anti-Virus Tools and Firewalls out there having similar features you should be aware of this problems.

You will notice the first problem when you try to show the upload progress. The ProgressEvent.PROGRESS bytesLoaded property will provide the bytes in the cache instead of the actual uploaded bytes. As a result your progress display will shoot up to 100% immediately on a fast Computer.

Be also careful with the usage of DataEvent.UPLOAD_COMPLETE_DATA as it doesn’t get dispatched once in a while while using the HTTP traffic scanning. Basically I guess the returning data is absorbed by the proxy, which handles the Anti-Virus cache.

The last issue is very weird but apparently Event.COMPLETE is fired before the file is completly uploaded to the server, therefore the file is not available just after the COMPLETE event, in case you want to call a convert script or something similar right after the upload. My assumption is that the proxy generates an HTTP status code of 200 which triggers the flash event when the cache is filled.

Lately I experienced some problems with FileReference upload while using Kapersky Anti-Virus Software. The software has a feature to scan HTTP traffic for viruses which btw. is enabled by default....

beyond 8191px

September 23rd, 2008 • 2 comments ActionScript, Flash
Tags: AS3, BitmapData

The limit of 8191px (or 0x1FFF in hex) is probably less known but it’s actually the maximum size for DisplayObjects. If your objects width or height is greater than this limit it won’t get rendered anymore.
I mentioned in an earlier post that you can create even bigger DisplayObjects with BitmapDataUnlimited. This is still true even though there are a few restrictions.

I put together a small demo to show you my results:
http://projects.formatlos.de/spiking/1fff/
click inside the window to gain Keyboard focus,
use your arrow keys to move the container 1px (hold shift: 10px, hold alt: 100px)

add via Bitmap, no scale

...
// hugeBitmapData: w=9000, h=10
container.addChild(new Bitmap(hugeBitmapData));
...

This is probably the most convenient way to add a BitmapData to the stage. As you can see in the demo this works perfectly.

add via Bitmap, scale -> width=8191

...
// hugeBitmapData: w=9000, h=10
container.addChild(new Bitmap(hugeBitmapData));
container.width = 8191;
...

The same as above, just scaling down the Sprite to 8191px. It seems to work but moving the container some px to the right shows a strange rendering behaviour.

add via Bitmap, scale -> width=8192

...
// hugeBitmapData: w=9000, h=10
container.addChild(new Bitmap(hugeBitmapData));
container.width = 8192;
...

This time scaling down the Sprite to 8192px which is 1px above the limit and therefore doesn’t get rendered. moving the container some px to the right shows the same strange rendering behaviour again.
If you move the container off the stage (to the left) the exact amout of px exceeding the limit, in our case 1px, the Sprite gets rendered again. I presume Flash Player calculates the significant width/height based on the DisplayObjects bounds relating to the stage and by moving the Sprite off the stage the width/height which has to be rendered is smaller than the limit.

add via graphics, scale -> width=8192

...
// hugeBitmapData: w=9000, h=10
container.graphics.beginBitmapFill(hugeBitmapData);
container.graphics.drawRect(0,0,hugeBitmapData.rect.width,hugeBitmapData.rect.height);
container.graphics.endFill();
container.width = 8192;
...

Apparently there is no such limit for the Graphics Object therefore you can use beginBitmapFill and drawRect to draw your BitmapData to a Sprite and scale it afterwards.

Download Demo Source

The limit of 8191px (or 0x1FFF in hex) is probably less known but it’s actually the maximum size for DisplayObjects. If your objects width or height is greater than this...

stereosucker.de

September 22nd, 2008 • ActionScript, Flash, Projects
Tags: AS3, SWFAddress, swffit

One of my latest projects just launched last week. It’s a portfolio site for visual artist and interface designer stereosucker aka Tine Päch.

The site is completely dynamic and provides deep linking and browser button support through SWFAddress.

Homepage

Projectpage

One of my latest projects just launched last week. It’s a portfolio site for visual artist and interface designer stereosucker aka Tine Päch. The site is completely dynamic and provides...