Flex / Spark Organization Chart (v2)

Rebuilt from scratch

Due to the popularity of the original organization chart (post can be found below) and the demand for it, I’ve rebuilt the component and made it available as open source.
Not that I love creating hierarchical data charts (though I must admit, it is fun), but the previous version was not ready to be openly released.

It didn’t follow Flex standards, the datasource had to be an XML file, etc… Not that the component is no good, it was just too specifically designed for the client back then.

In short, here’s the new version, and it boasts quite a few good features :
- Full Spark component architecture, meaning everything you see can be spark-skinned.
- Support for massive amouts of nodes
- Data can be any IList, in the demo it is an ArrayCollection. As with any Flex/Spark component, direct changes to the dataProvider collection result in the component updating itself, and vice-versa.

Layout calculations through Alchemy

Besides building it on Spark, the other new feature is that it crunches most calculations using Alchemy.

The layout is done with Alchemy, using a recursive function, which calculates every x and y position of each node.
Afterwards, another Alchemy function will return only those nodes that need to be rendered.

For example, you have a dataprovider of 1000 nodes, Alchemy will position each node, resulting in a viewpane of 10000×1000 pixels for example, yet the component itself in the Flash player is only 400×400 in size. For that 400×400 rectangle, Alchemy will return which nodes fit into that pane.
As a result, the player will never render all 1000 items, yet only those viewable.
As you scroll, the rendererd nodes will be recycled as Alchemy returns different nodes as you scroll.

To gain as much speed as possible, Alchemy function calls are kept to a minimum, and changes to the dataProvider are transferred directly into Alchemy memory.
When done calculating, the component in its turn will read all data from Alchemy by reading directly from the Alchemy memory ByteArray.

Design freedom

As noted above, the whole component can be skinned as you would any other Spark component.
Now 3 states are supported, minimized-normal-maximized.
In the demo, the maximized state implements an Image component and a DataGrid component.
The line connectors between 2 nodes can also be altered with the skin, where you can specify if lines should enter or exit from top, bottom, left or right of the node.

Bottleneck?

Even though I’m happy with the result, since you have to keep in mind that the whole chart starts out with all nodes expanded, the current bottleneck appears to be the rendering of many nodes on screen at once. The current skin does use a lot of gradients, but I’ll try to make it go smoother over time…

*** update *** I upped a version boasting 10000 items, which might criple performance on lower end computers.

Click on the image below or here to go to the style explorer.
If you are looking for the source, I’ve placed it at google code.

It’d be appreciated if you post your performance experience, I’ve set the item count on 5000 for the moment, which should make it run reasonably adequate on most computers.

Unfinished project #8267909202841

Well…
Title kind of speaks for itself!

I had this vision of my (smart)phone filling up with water, which you could shift using the accelerometer.
In other words, tilt the phone and the water starts flowing.

On top I envisioned it to be running in a maze, so you could get a decent puzzely kind of game out of it, for example by adding some floating or swimming objects which need to get from A to B and maybe even a C.

Alas, lack of time (and honestly the engine is slowing the player down too much) prevented this thing from ever surfacing.

Nevertheless, since this is after all a labs thing, feel free to toy around with is here!

Behind the scenes everything is done with Alchemy, apart from some filters applied in AS3.
It is reasonably speedy, but it will (for now) not quite run yet on any uber-specced smartphone :-/

Eagerly awaiting mobile AIR 2.0/Flash 10.1

It seems like an eternity, waiting for the official release.
Especially with all the commotion recently give Apple’s infamous section 331, and the following hatred towards the Flash platform.

I could write a lengthly paper on my thoughts on the matter as a whole, yet those opinions can already be found all over the net in both the Flash and Apple camps.
As I haven’t personally had the honour of toying around with, say the Android beta of AIR 2.0, let alone mobile Flash 10.1, I’m just going to await the official release and see if Adobe will manage to silence the negativism surrounding their platform.

Meanwhile, I’ve prepped up this demo on a rainy day. Very suitably, it is a simulation of running water in a maze. It’s an idea I have for a potential Flash game, but again, only time will tell if it will even manage to run well on a mobile device.

Benchmarking on my laptop so far, has given very different results.
In AIR 2.0 beta it runs very well, same with the standalone Flash 10 and Flash 10.1 players, but once loaded in a browser, it becomes painfully slow.

The engine was written in C# with Alchemy, basically the only AS3 code that is used, is to update the main Bitmap object on each frame.
The engine will add water particles every frame, until the count reaches 50000 water particles.

Feel free to have a go by following this link, benchmark posts are more than welcome!

Astar pathfinder with Pixel Bender and Alchemy

draw a maze with the mouse

The biggest limitation was that everything is always grid-based. You would simple flag certain nodes in the grid as walkable and not walkable and then calculate the best path.

Why Pixel Bender for a path finder?
My initial goal was to have the astar pathfinder run on a pure black and white bitmap data object. This way a designer could simply place complex objects on a map and a developer could easily transform the map to a black and white collision map.
The next step of course would be to have Flash analyse this bitmap and create a grid for pathfinding accordingly.
Using getPixel in a loop would be very slow, especially in very large bitmaps, so Pixel Bender was obviously used here.
A cool bonus is that Pixel Bender also runs asynchronously in a seperate thread from Flash.

How does Pixel Bender create the grid?
The Pixel Bender kernel script takes 2 parameters, one being the black and white bitmap obviously, the other being a node distance value. This node distance is the effective distance between 2 individual nodes in the grid. For example: a bitmap of 600 pixels width would output 30 columns in the node distance is 20 pixels.

As you probably know, Pixel Bender loops over each individual pixel.
For each pixel, the node to the top-left of that pixel is found. Then the script will test if the current pixel happens to be in a straight line between 2 adjacent nodes.
If it is, another test will determine if you can walk from node A to B, this is not the case should the pixel be black.

For each pixel, a result is kept. The output of the Pixel Bender kernel script is image3, so that gives 3 values for each pixel to use.
The first value is a binary value, this binary value is a collection of bit flags for the pixel, namely : is walkable or is not walkable, if the pixel is on the straight line to the node on the right/bottom-right/bottom/top-right.
The other 2 values are used to store the col and row of the top-left node.

For quick updating I also divided the black and white bitmap into areas, each area is 200×200 pixels large and is processed by its own ShaderJob. This way, when the black and white map is updated, I can process these updates by area instead of having to re-process the image as a whole each time.

Now for Alchemy…
Thanks to Ralph Hauwert’s excellent post on how to optimize the use of Alchemy and Pixel Bender, I decided to try the same with this experiment.
Flash will write the Pixel Bender result straight into Alchemy memory, where it is then processed in C to a usable grid.
The actual astar algorythm was also ported to C since the algorythm potentially runs a very large loop when using low node distance values or large black and white collision maps.

As a result
The path finder does run faster than in pure AS3, but not by a great amount. You can test it here.
The initial choice is to set the node distance property. The lower the value, the more nodes Pixel Bender will generate and thus the more data Alchemy has to crunch to display the astar path result.

Please note that…
the initial choice can really result in a slow pathfinder if you select ‘intensive’ for example. In most practical implementations the less-intensive settings are more than enough.

Credit to mr. Doob for the excellent Stats class

c code used in Alchemy
Around 90% of this app was built in C for use in Alchemy, below is the source.
It’s a bit cryptic sometimes, mostly due to some efforts in trying to optimize code execution with Alchemy.
Flash is only used to paint the maze and display the result from Alchemy & PB.

Alchemy C source