FlashLite 2.1 Buggy!

[kazster]

I posted this on the flash lite forums at Adobe, but it's probably a good idea to post it here aswell:

I've noticed some pretty serious problems when when working with Flash Lite 2.1 on on a device, on a device simulator, and on the Flash 8 emulator. There were no Object watches or any other kind of behind-the-scenes mayhem when I found these bugs. Here's just a small list of issues that have gone wrong (among other things):

1. The Number data type is flaky at best. When doing a trace() on a variable of type Number, the value will change from signed to unsigned depending on what was done with the variable even if the actual contents haven't changed. For example I tried doing a bitwise OR on a Number that had 0xFFFFFFFF in it, and the interpretation switched from unsigned to signed.

2. It seems that when I do an add 0 to a _y member of one of my MovieClips the contents of my movie EXPAND AND SKEW to extreme extents. I don't even know how this is possible, because nowhere in my application do I modify _width/_height, or any scale property values of ANY MovieClip objects (only read them).

3. When testing my app on a device (LG VX8000), Flash Lite began IGNORING certain core language operations (adding / creating an empty movie clip / etc..) RANDOMLY if I start mashing keys fast enough (happens sometimes even if I don't mash keys).... operations which work 100% of the time in the Flash 8 device emulator both with a low and high FPS rate.

4. When retrieving _y and _height properties of a MovieClip, in certain places these properties were INTERCHANGED WITH EACH OTHER if I didn't add trace() calls to print their values before hand. Taking out the trace() calls caused the values to continue being swapped.


These are pretty serious issues that are making my app unstable all around. My application is entirely based on the basics of ActionScript 2.0. I can assure people reading this that the problems are not because of bugs within my application. Has anyone come across any of these problems before? Can anyone at Adobe provide information or workarounds/support.

It's a shame to see such huge bugs in the Flash Lite VM.

I don't really know what the NSTL/QUALCOMM requirements are for allowing extensions. How something like this has passed any kind of QA process is beyond me.

Here's an ActionScript demo that shows one of the most serious bugs (Bug number 3). Contrary to my prior belief, you don't even need to be mashing keys for the VM to start ignoring operations, on almost every iteration there'll be something wrong with the output on the screen (random missing blocks/ignored lineTo's) as opposed to having a screen with a full colour palette. This bug ONLY appear when testing on an actual device (in this case the LG VX9800), and doesn't happen at all on the Flash 8 emulator.

function drawSquares(mc:MovieClip) {
if (mc.innerClip != null)
removeMovieClip(mc.innerClip);

var innerClip:MovieClip = mc.createEmptyMovieClip("innerClip", mc.getNextHighestDepth());

var systemX:Number = System.capabilities.screenResolutionX;
var systemY:Number = System.capabilities.screenResolutionY;
var totalXBlocks:Number = 0xF;
var totalYBlocks:Number = 0xF;
var blockWidth = Math.floor(systemX / totalXBlocks);
var blockHeight = Math.floor(systemY / totalYBlocks);


for (var x:Number = 0; x < totalXBlocks; x++) {
for (var y:Number = 0; y < totalYBlocks; y++) {
var newClip:MovieClip = innerClip.createEmptyMovieClip(x + "x" + y, innerClip.getNextHighestDepth());

var color:Number = (y << 12) + (x << 4) + y;
newClip.beginFill(color);
newClip.moveTo(0, 0);
newClip.lineTo(blockWidth, 0);
newClip.lineTo(blockWidth, blockHeight);
newClip.lineTo(0, blockHeight);
newClip.lineTo(0, 0);
newClip.endFill();

newClip._x = x * blockWidth;
newClip._y = y * blockHeight;
}
}
}

setInterval(drawSquares, 1, this);

These bugs seem like they're pretty serious. I haven't gotten an answer from anyone at Adobe. I think it's almost as if though they have a "don't ask don't tell" policy when it comes to issues with Flash Lite.

[jmiller2]

I posted this on the flash lite forums at Adobe, but it's probably a good idea to post it here aswell:



I don't really know what the NSTL/QUALCOMM requirements are for allowing extensions. How something like this has passed any kind of QA process is beyond me.

Here's an ActionScript demo that shows one of the most serious bugs (Bug number 3). Contrary to my prior belief, you don't even need to be mashing keys for the VM to start ignoring operations, on almost every iteration there'll be something wrong with the output on the screen (random missing blocks/ignored lineTo's) as opposed to having a screen with a full colour palette. This bug ONLY appear when testing on an actual device (in this case the LG VX9800), and doesn't happen at all on the Flash 8 emulator.

function drawSquares(mc:MovieClip) {
if (mc.innerClip != null)
removeMovieClip(mc.innerClip);

var innerClip:MovieClip = mc.createEmptyMovieClip("innerClip", mc.getNextHighestDepth());

var systemX:Number = System.capabilities.screenResolutionX;
var systemY:Number = System.capabilities.screenResolutionY;
var totalXBlocks:Number = 0xF;
var totalYBlocks:Number = 0xF;
var blockWidth = Math.floor(systemX / totalXBlocks);
var blockHeight = Math.floor(systemY / totalYBlocks);


for (var x:Number = 0; x < totalXBlocks; x++) {
for (var y:Number = 0; y < totalYBlocks; y++) {
var newClip:MovieClip = innerClip.createEmptyMovieClip(x + "x" + y, innerClip.getNextHighestDepth());

var color:Number = (y << 12) + (x << 4) + y;
newClip.beginFill(color);
newClip.moveTo(0, 0);
newClip.lineTo(blockWidth, 0);
newClip.lineTo(blockWidth, blockHeight);
newClip.lineTo(0, blockHeight);
newClip.lineTo(0, 0);
newClip.endFill();

newClip._x = x * blockWidth;
newClip._y = y * blockHeight;
}
}
}

setInterval(drawSquares, 1, this);

These bugs seem like they're pretty serious. I haven't gotten an answer from anyone at Adobe. I think it's almost as if though they have a "don't ask don't tell" policy when it comes to issues with Flash Lite.


I'm not much of a Flash Lite person, but looking at your code I
have a few questions.

It looks like you are creating an array of movie clips, but using the
same local variable over and over to store them. How is it possible to
reference these movie clips uniquely later? If you don't need to
then what is cleaning up memory in between? Perhaps there is a
scope problem?

var newClip:MovieClip = innerClip.createEmptyMovieClip(x + "x" + y, innerClip.getNextHighestDepth());

perhaps try,

newClip:MovieClip[x][y] = innerClip.createEmptyMovieClip(x + "x" + y, innerClip.getNextHighestDepth());

Defining an array of them earlier in the code? Does AS 2.0 support
2 dimensional arrays?

Do you have the above problems with only a single movie clip?
Perhaps there is an issue with memory, etc on how many individual
clips you can have operating at once.

The handset does not have the type of threading operations that
will be available on the emulator. In your case it might be better to
draw the blocks individually rather than making each one a movie clip.
Perhaps the engine does not handle low memory situations well.

There's really no way NSTL is going to be able to test every permutation
of AS on the device. They are given a sample application to test the
app with and it is up to the developer (in this case Adobe) to fully
exercise the extension with the sample code. Even then, all software
has bugs so the best you can do at this point is probably figure out
how to work around them and make sure they are reported to the
right people so they can be fixed in the next version of the extension.

I'll look for Adobe at when I'm at GDC tomorrow and see if they are
aware of this issue.

---jeff

[kazster]

Hey Jeff,

I can assure you that the AS2.0 code is valid and functional on normal Flash, the Flash 8 emulator, and the BREW 3.1.5 Simulator. I'm not a flash expert but I believe the child MovieClips can be directly accessed through the parent MovieClip, they're contained as properties. They can be uniquely accessed by the MovieClip name I passed in to the createEmptyMovieClip method. As you can see the MovieClips will end up being named 0x0, 0x1, 0x2,..., 0xF, 1x0, 1x2, ............ 15x15. The child MovieClips are created by and stored within the parent MovieClip, there's no point in me creating an array because they're already there and can be uniquely accessed through there.

ActionScript aside. It's not just this one problem with FL2.1, there are many many problems that are coming up, some of which are show-stoppers. The one I posted above is an example of what I consider one of the more serious ones. It looks like the VM is ignoring operations RANDOMLY. Out of the 16*16 squares I'm drawing each iteration, there's bound to be one that's half complete (one of the lineTo's got ignored so it ends up being a triangle) or one that's completely not there at all. At first I thought there was something wrong with my application's code, but I wrote the above demo to verify that it was indeed something to do with the Flash Lite VM.

I know that all software has bugs. However, when it comes to VMs I think core stability is one of the more important pieces. Imagine having to write software on a platform that randomly ignores add/subtract/compare/etc.. operations. It wouldn't be very pleasant.

In anycase, thank you for your concern. If you find anything out at GDC please make sure to PM me :)

- Kaz

[jmiller2]

Hey Jeff,

I can assure you that the AS2.0 code is valid and functional on normal Flash, the Flash 8 emulator, and the BREW 3.1.5 Simulator. I'm not a flash expert but I believe the child MovieClips can be directly accessed through the parent MovieClip, they're contained as properties. They can be uniquely accessed by the MovieClip name I passed in to the createEmptyMovieClip method. As you can see the MovieClips will end up being named 0x0, 0x1, 0x2,..., 0xF, 1x0, 1x2, ............ 15x15. The child MovieClips are created by and stored within the parent MovieClip, there's no point in me creating an array because they're already there and can be uniquely accessed through there.

ActionScript aside. It's not just this one problem with FL2.1, there are many many problems that are coming up, some of which are show-stoppers. The one I posted above is an example of what I consider one of the more serious ones. It looks like the VM is ignoring operations RANDOMLY. Out of the 16*16 squares I'm drawing each iteration, there's bound to be one that's half complete (one of the lineTo's got ignored so it ends up being a triangle) or one that's completely not there at all. At first I thought there was something wrong with my application's code, but I wrote the above demo to verify that it was indeed something to do with the Flash Lite VM.

I know that all software has bugs. However, when it comes to VMs I think core stability is one of the more important pieces. Imagine having to write software on a platform that randomly ignores add/subtract/compare/etc.. operations. It wouldn't be very pleasant.

In anycase, thank you for your concern. If you find anything out at GDC please make sure to PM me :)

- Kaz

When these operations are failing is there any way to check return codes
or look at the output of the BREW logger?
(e.g. does newClip.lineTo have a return value?)

I appreciate your position. In fact, it is why I choose to avoid using any
kind of runtime when at all possible (unless source is supplied or the
developer is willing to fix bugs rapidly). I've just been burned too many
times. C++ (almost) never lets me down.

I'll let you know if I get any new information from Adobe in the next few days.


---jeff

[ruben]

For clarification, if you run the above content in the desktop flash 7 player, what behavior do you see? Do you see the similar error?

[kazster]

For clarification, if you run the above content in the desktop flash 7 player, what behavior do you see? Do you see the similar error?

The application runs without any errors when I run it under the Flash 8 emulator, or publish it as a normal desktop Flash 7 file and view it. As for running it under the actual Flash 7 player, it doesn't look like it's available for download anymore.

Like I said in my previous posts, the only place I'm seeing this error is on the actual device. If you require anymore information, don't hesitate to ask.

[kazster]

Looks to be happening on V3C aswell :(