[Bindable]? No, thanks

Working on huge projects sometimes let you take long optimization sessions.
During one of these sessions I was trying to find a way to optimize a bunch of code which was taking too long time to process.
The big big bottleneck I discovered, and I didn’t know before (my fault), was the **[Bindable]** attribute of one of the classes included in the process.
This process was creating something like 1 million instances of this class during its life. After a first optimization in which I created an object pooling, thus reducing the total execution time from 16 seconds to 13, I found this incredible trick which reduced the total execution time to **1 second!!**

Let’s say you have a class like this:

package it.sepy.test
{

[Bindable]
public class RGB
{
private var _blue: int;
private var _green: int;
private var _red: int;

public function RGB()
{
}

public function get blue(): int
{
return _blue;
}

public function set blue( v: int ): void
{
_blue = v;
}

public function get green(): int
{
return _green;
}

public function set green( v: int ): void
{
_green = v;
}

public function get red(): int
{
return _red;
}

public function set red( v: int ): void
{
_red = v;
}
}
}

and a simple script which create 100000 instances of this class (my script wasn’t like this, but for simplicity I’m doing this example):


package
{
import flash.display.Sprite;
import flash.system.System;
import it.sepy.test.Pool;
import it.sepy.test.RGB;

public class test extends Sprite
{
public function test()
{
startTest();
}

private function startTest(): void
{
var t1: Number = new Date().getTime();
for ( var i: int = 0; i < 100000; i++ ) { var rgb: RGB = new RGB(); rgb.red = i % 255; rgb.green = i % 255; rgb.blue = i % 255; } var t2: Number = new Date().getTime(); trace( 'total execution time:', ( t2 - t1 ), 'ms' ); trace( 'memory usage:', System.totalMemory / 1024, 'kb' ); } } }

now launch the script and in the output I have this result
total execution time: 2381 ms
memory usage: 5924 kb

NOW. Remove the **[Bindable]** property from the RGB class and launch again the test script. See at the output console and the new results are:
total execution time: 236 ms
memory usage: 2720 kb

So, I know that bindable were not created for this kind of jobs, but if using it make 10 time slower my scripts, then I don't see any valid reason to use it anywhere.

Multiple objects using Senocular TransformTool

Senocular TransformTool is one of the best and most used components around the net. It is really useful for those (include me) who don’t want to fight against Matrix, concatenation of Matrix and all those painful stuff…

The only ‘lack’ of that component is that it does not support multiple objects as target. If you want to transform n array of elements at the same time you should have all those elements in the same parent DisplayObjectContainer and then set that parent as target of TransformTool.

But maybe sometimes this is not possible due to various reason and you want to use different items with different parents as dataprovider.

This is the solution I actually use for that particular situation (Remember that I’m using a modified version of the TransformTool)

This is the final result: ( Ctrl+click on the tree leaves to multiple selection )

Live Demo of the Trasform Tool using multiple objects

( Here you can download download the source files ).

In few words the solution I found is this:

Create a temporary layer which will be the TransformTool target.
For every item in the selection Array create a temporary shape with the size of the getBounds() of the real object. Store this shape into the temporary layer, assigning to it the concatenated matrix of the real object.

Once there’s a transformation of the temporary layer get every shape transform matrix and assign back to the original object.

Probably there are many and better solutions to do the same, this is just the one I found, maybe someone has better approach to this problem (and he is welcome here!)

A long journey through chunked transfer and file uploading

It has been a while since I wrote the last post … I know, I’ve still quite a lot of stuff left opened but sooner or later you’ll get it. Don’t worry 😉

During the last days I’ve been working on improving some server side API for a client I’m working for.

Actually they’re using a mix of AMF and HTTP based API but, as long as the AMF implementation is unfortunately a bit unstable, they want to move to a full HTTP based API … that sounded quite easy: take a bit of HTTP, dress it with POST and maybe XML (or whatever other ingredient you like most) and you’ll have a good base to start porting the API.

But I’ve ignored a small particular that turned out to be really painful to manage by using just HTTP: sending efficently to the server big chunks of binary data.

Those were the requirements I had to fulfill:

  1. I have potentially really big binary files to be sent quickly to the server;
  2. I have to track upload progress somehow;
  3. I must be able to trigger the upload without the user interaction;
  4. I should rely on HTTP only;

And here the solutions I’ve tried to implement, and the conclusions I’ve achieved (well, I didn’t try all the options because I already knew that a few of them were not suitable for my situation, but they might be useful to someone and so I’m reporting them anyway).

Continue reading

Silverlight 3.0 beta

Today I discovered this page about the upcoming Silverlight 3.0 and I was really surprised about the ton of new features they are adding in this new release. In fact, reading at the features list it confusing me… it seems to me like I was reading a page with the flash player capabilities.. more or less.

If SIlverlight 2.0 was comparable, more or less to flash 5, I believe ( but I should test it before ) that this new version has quite all the features of flash 10.

  • Support for Higher Quality
  • Live and on-demand true HD
  • Perspective 3D Graphics
  • Pixel Shader effects
  • Bitmap Caching
  • New Bitmap API
  • Themed application support
  • Improved text rendering & font support
  • Deep Linking
  • Search Engine Optimization (SEO)
  • Element to Element binding
  • Application library caching
  • Binary XML allows communication
  • Local Connection
  • Out of Browser Capabilities

Moreover, dont forget, Silverlight has a couple of advantages above flash: a more powerful vector rendering engine and threads capabilities.

Read the full article here: http://silverlight.net/themes/silverlight/getstarted/sl3beta.aspx?AspxAutoDetectCookieSupport=1#whatsnew

P.S. …just because I continued following links around MS pages I also came across a new feature microsoft will add to C#, one of those features I always envy to python: the named arguments. I really find it useful, instead of writing twenty null arguments ( like when you create a textformat… ) you simply call arguments by name.

AsYacc – first alpha release

Before going further with discussing how to add runtime scripting support to a Flash applications, I’d like to share with you the source code of a porting of Yacc I did a while ago. I did some simple modification to make Yacc able to generate ActionScript 3.0 source code instead of C. It works quite well and supports a lot standard Yacc features. There might be some issues – report them to me and I’ll try to fix them 🙂

You can easilly find documentation about Yacc searching Google (you can start here for example).

Usually Yacc is used in conjunction with a Scanner generator (like Lex/Flex), but I didn’t to any porting of commonly used Scanner generators yet.

Here you can download the sources. The source code should be portable and compilable on all the most common platform, but I didn’t tested it on Windows yet. To compile the source code on Mac or Linux, cd to the source code directory and type use:

gcc *.c -o AsYacc

Once you have the compiled binary file, you can run the Parser generator using:

./AsYacc -Hpackage=it.sephiroth.test grammar.y

Where grammar.y is a text file that contains the grammar of a language defined using the proper syntax (see the docs online for all the detailed information you may need).

Here you can download a simple calculator example that uses the RegexLexer described previously to implement the Scanner. For the ones who might be interested, here is the grammar used:
/* Infix notation calculator. */
%{
%}
%token NUM
%left '-' '+'
%left '*' '/'
%left NEG
%right '^' /* exponentiation */
%%
input:
exp { trace( $1 ); }
;
exp:
NUM { $$ = $1; }
| exp '+' exp { $$ = $1 + $3; }
| exp '-' exp { $$ = $1 - $3; }
| exp '*' exp { $$ = $1 * $3; }
| exp '/' exp { $$ = $1 / $3; }
| '-' exp %prec NEG { $$ = -$2; }
| exp '^' exp { $$ = Math.pow( $1, $3 ); }
| '(' exp ')' { $$ = $2; }
;
%%

Loading images via http vs bytearray

Load images via http or using bytearray? which the best way?
It was long time since I wanted to perform this kind of test, but for different reasons I never had the time to do that.
Some days ago fnally I’ve found the time thanks to a project I’m involved into.
The problem.
A local webserver running flash remoting via pyamf and a flash standalone application which need to load tons of images locally.
I’ve noticed that sending from amf the list of images path to be loaded required too much time (for me), even if they’re loaded locally.
Because of this I decided to try a first benchmark loading a single image using the standard way: send the link from amf and then load it using the classic actionscript Loader.
The second test was to send directly from amf the image stream using a ByteArray and then loading the image in flash using the Loader.loadBytes method.
In this way I’ve noticed that the second task requires less time than the first one (more or less 40% less).
Unfortunately our application needs to load something like 50/100 images at the same time.
For this reason I did a new test loading 22 images of 500Kb each (10Mb total). For a better result I decided to use both pyamf and blazeds, to be sure there’s no problems in the language used. Moreover I used charles to register the benchmark of these tasks.
The results were unexpected!
First test: passing form amf the list of url images and loading using the standard flash Loader to load all of them simultaneously.
The time elapsed from the flash method call to the results was about 40 milliseconds. Then from the remote method result to the completion of all Loader about 1400 milliseconds.

Second test: passing from amf an arraycollection of bytearrays containing all the images stream to be loaded directly in flash.
The time elapsed form the flash method call to its result: about 2900 milliseconds. Time elapsed from the result to the all Loaders completion: about 900 milliseconds.
This results were unexpected for me, expecially because both with blazeds and pyamf sending 10Mb of bytearrays tooks something like 3 seconds!
At a first impression I thought the problem was the time for java and python to create the amf stream data, but after a deeper test I discovered that they took more or less 30ms to generate the amf stream and the real bottleneck was the http transfer of this stream data.

I’m attaching here the screenshots of the charles sessions using blazeds:

Here you can find also the complete benchmark result using flash trace within the swf:
————————–
BlazeDS
————————–
Method Elapsed-Time
call.test1 0
result.test1 40
complete.test1 1453
TEST1 TOTAL TIME: 1493
call.test2 0
result.test2 2919
complete.test2 921
TEST2 TOTAL TIME: 3840
————————–
PyAMF
————————–
call.test1 0
result.test1 32
complete.test1 953
TEST1 TOTAL TIME: 1049
call.test2 0
result.test2 2805
complete.test2 908
TEST2 TOTAL TIME: 4763
Here you can see the source code used for these tests:
In conclusion. While sending 10Mb of data ( for example bytearray ) requires more or less 2.5 seconds using flash remoting as single requests ( because the transfer rate of the webserver it’s about 4Mb/sec ), loading simultaneusly 20 images from the webserver, using http, tooks 1 second.
This is because the webserver for each requests opens a different thread to dispatch the request and in this way the total time to perform this task is less than the first method.

Scripting Flash apps: design the language

Finally I had a bit of time to go back to the discussion I started about a month ago: scripting your flash applications. I spent a bit of time thinking which is the best approach to start discussing this kind of topic; it is not as easy as it seems because the risk is to fall into a too complex discussion that a lot of people won’t benefit from.

So I decided to start with a simple example that is somehow related to what I’m doing in these months; more examples will come and I’ll analyze different aspects of scripting trying always to keep the discussion as simple as possible even if this may bring me to do avoid some hard to discuss approaches or optimizations.

Our first scripting language will be an extremely simple language that will be used to manipulate images (like Pixel Bender does). Obviously the goal is not to write something that can be compared with Pixel Bender, but at least we would like to provide an implementation that will lead to scripts as fast as native code (at least we hope so :P).

The first step is to design the language, and to do that we need to do the step zero that is to define the goals we want to achive with the first implementation:

  • The language must be extremely simple to design and implement (it is a didactic stuff indeed!);
  • The language must be as simple as possible to learn and use: we won’t be an alternative to Pixel Bender (because we can’t … yet ;P)
  • The language must be quick to compile and execute.
  • A script must accept some parmeters to control its behaviour.
  • We must support comments!

Now that we decided which are the goals, let’s start definign some limitation or features we must include to quickly reach a solution:

  • The first implementation of the language will support a sigle data type: Numbers. We will move further adding more data types later – I don’t want to focus on type checking yet.
  • We will add support for basic expression operators, basic control flow. No support for functions yet.
  • The language will provide some useful operators or builtin functions to manage common operations like packing/unpacking color components and peform some mathematical operations.
  • Arguments to a script will be only Numbers at first.
  • A script will be defined as a simple sequence of arguments followed by a function definition. This function will be applied sequentially to every pixel of one or more source images.
  • We will provide to implementations for the language: a simple (and slow) interpreter at first, then we will generate native SWF code to speedup the performances.

Even if briefly, it is quite important to define the goals of our language and then the features, because a lack of design (even if extremely simple and poor as the current one :P) may lead to unexpected issues during implementation.

Now that we defined those basic pointers, let’s see how the language will look like:
// Simple crossfade filter
// The crossfade intensity
argument intensity;
/**
* A quick explanation of the used builtins:
* - in( id, x, y ): gets the ARGB color at x and y of the image identified by id (there can be more than one image as input);
* - out( id, x, y, color ): sets the ARGB color at x and y for the output image identified by id;
* - argb( a, r, b, b ): build an ARGB color from its components (clamping and rounding the values as required);
*/
evaluatePixel( x, y )
{
// this kind of assignment is similar to the python unpack assignment
// but extracts the 4 components (ARGB) from a color.
a1, r1, g1, b1 = in( 0, x, y );
a2, r2, g2, b2 = in( 1, x, y );
out( 0, x, y, argb(
( 1 - intensity ) * a1 + intensity * a2,
( 1 - intensity ) * r1 + intensity * r2,
( 1 - intensity ) * g1 + intensity * g2,
( 1 - intensity ) * b1 + intensity * b2 ));
}

As a side not, I must say that the language may change during implementation because of unexpected limitations we will find during development.

Next week we will move forward start implementing the language. Stay tuned!

Scripting your Flash applications …

As someone of you may know, I really like studying programming languages and sometimes implement for fun (or for work) simple scripting languages that help me out during development.

The fight between scripting and programming languages will probably never end. Well, it is not really a fight but more an infinite race where the first position is exchanged continuosly between the two participants.
We need flexibility first, and so we add to our complex applications a way to support scripting to be able to easilly perform changes without the need to run the long time taking compilation process a low level language might take; then, the more the scripts became complex, the more we need an increase in performances, and so we rapidly move to compiled plugin egines; plugins offer a bit of flexibility and usually a good speed. Then we grant other users the permission to write plugins and so we need a sandbox to run the plugins in and to be sure every single line of code that is executed doesn’t harm our application. And so we revert back to scripting … and so on.
The race will never end but the technologies will continue to increase in speed and sometimes in complexity.

All the introduction is to say that its not the point to choose if scripting is useful or not for Flash applications, but to say that someone might need it for reasons we cannot think about right now, and someone else might not need it because they are fine with recompiling everything from scratch at each single small change.

I don’t think there are some many Flash applications that support scripting. I built myself a few of them for my company but they are for a particular purpose and probably the same motivations that made me decide to implement a scripting language are hard to find for other kind of applications.

As far as I know, the most of the applications that need to be flexible use a plugin system (more or less complicated – as Aviary for instance and Hobnox) and are fine with it because – we must say that – ActionScript is itself a scripting language and a SWF file is nothing more than a bunch of instructions (more or less) generated by compiled ActionScript.

But sometimes security comes into account, and it is hard (even if possible) to limit the funcionalities used by a plugin if this plugin is created by a 3rd party developer.

And so it comes into account scripting. With scripting we have full control over what a developer can do an how he can do that. We can limit it, provide builtin functionalities … But everything costs something, and building a fast/flexible/powerful/useful scripting languages is not that easy as it might seem.

This is why I decided to spend a bit of time in explaining the basics to implement a scripting language in actionscript to be able to script our applications. I’ll walk through all the passes – from lexing to bytecode generation and maybe a quick look into Virtual Machines – with the aim to provide someone (maybe in the far future) a bunch of documents to use as reference to build their own scripting language.

I’ll try to give an in depth look, but as far as the argument is quite complicated and full of facets, you may not find here the right solution for you. Nor the fastest or the most flexible. But it is better then nothing so if you are interested in that keep reading the blog 🙂