The most common technique that I see artists and developers using involves  rendering bitmaps from a display object. Rendering a bitmap of your display objects is a great way to keep the memory of your piece under control. If you were to just leave every Shape, Sprite or MovieClip you created on the stage, the memory your piece consumes would continually grow and eventually cripple your piece. So what you do is render a bitmap every so often and discard any "dead" display objects. By "dead" I mean display objects that are not animating or updating themselves in any way. Its a pretty simple technique. The following example illustrates how this is done:

The code for this example looks like so:

import flash.display.Sprite;
import flash.display.Shape;
import flash.display.Bitmap;
import flash.display.BitmapData;
import flash.events.MouseEvent;
 
var circles:Sprite = new Sprite();
 
var bitmapData:BitmapData = new BitmapData( stage.stageWidth,
	stage.stageHeight, true, 0x00FFFFFF );
bitmapData.draw( circles );
 
var bitmap:Bitmap = new Bitmap( bitmapData );
addChild( bitmap ); 
 
function onStageClick( event:MouseEvent ):void
{
	for( var i:int = 0; i < 10; i++ )
		circles.addChild( getRandomCircle() );
	bitmapData.draw( circles );
	while( circles.numChildren )
		circles.removeChildAt( 0 );
}
 
function getRandomCircle():Shape
{
	var c:Shape = new Shape();
	c.graphics.beginFill( Math.random() * 0xFFFFFF );
	c.graphics.drawCircle( 0, 0, Math.random() * 100 );
	c.graphics.endFill();
	c.x = Math.random() * stage.stageWidth;
	c.y = Math.random() * stage.stageHeight;
	return c;
}
 
stage.addEventListener( MouseEvent.CLICK, onStageClick );

In this example a bitmap is rendered based on the contents of the circles Sprite object every time the user clicks the stage. However, before the bitmap is rendered, 10 random circles are placed inside the circles Sprite. After the bitmap is rendered, the random circles are removed. One of the best parts of rendering a bitmap is that you don't have to continually create new BitmapData or Bitmap objects when its time to render. If you add more display objects to your subject and want to render them in the bitmap you just have to call the draw() method on the BitmapData object again. Also, notice that the memory used by the piece doesn't increase over time even thought it looks like you're adding hundreds of display objects to the stage. Cool stuff.

The One Small Annoyance

As I've been messing around with this stuff I came across a little oddity which caused me great annoyance for a few hours. I decided to start adding filters to the shapes I was creating. No big deal, right? Well, lets take a look at what I did by adjusting the previous example to apply a BlurFilter instance on each circle that's created.

The code for this example looks like so:

import flash.display.Sprite;
import flash.display.Shape;
import flash.display.Bitmap;
import flash.display.BitmapData;
import flash.events.MouseEvent;
import flash.filters.BlurFilter;
 
var circles:Sprite = new Sprite();
 
var bitmapData:BitmapData = new BitmapData( stage.stageWidth,
	stage.stageHeight, true, 0x00FFFFFF );
bitmapData.draw( circles );
 
var bitmap:Bitmap = new Bitmap( bitmapData );
addChild( bitmap ); 
 
function onStageClick( event:MouseEvent ):void
{
	for( var i:int = 0; i < 10; i++ )
		circles.addChild( getRandomCircle() );
	bitmapData.draw( circles );
	while( circles.numChildren )
		circles.removeChildAt( 0 );
}
 
function getRandomCircle():Shape
{
	var c:Shape = new Shape();
	c.graphics.beginFill( Math.random() * 0xFFFFFF );
	c.graphics.drawCircle( 0, 0, Math.random() * 100 );
	c.graphics.endFill();
	c.x = Math.random() * stage.stageWidth;
	c.y = Math.random() * stage.stageHeight;
	c.filters = [new BlurFilter( 150, 150 )];
	return c;
}
 
stage.addEventListener( MouseEvent.CLICK, onStageClick );

You should notice occasionally that when the bitmap is rendered there are some clipping issues. You might see some hard lines on a blurred circle as if it was masked. This not only occured for BlurFilter instances, but also any other filters with blur-like effects, such as DropShadowFilter and GlowFilter. The following screen shot illustrates this:

I couldn't for the life of me figure out what was causing this to occur until I accidentally stumbled across a fix while creating these examples. To avoid the clipping, simply add the display object that you're rendering to the stage. Why this works is beyond me, but at least its a fix. As an additional performance measure, you can set the visibility of that display object to false. In the case of these examples we're talking about the circles Sprite. Adjust the line where the circles Sprite is created to look like this:

var circles:Sprite = new Sprite();
addChild( circles );
circles.visible = false;

And the resulting piece should render properly like so:

While this is just a basic example, this technique can be applied in many different ways to improve performance. For example, I've been working on a painting program that paints a loaded image using organic moving brushes that uses a similar technique. The brushes even animate a bit before the are discarded. At any rate, I hope to find more time to be able to share more things that I find useful while working with generative art. Until then, please post questions or any suggestions to techniques you find useful!

1. Its in F*ckin' New York City!
I know NYC isn't for everyone but there's everything you could imagine here. On top of learning and getting inspired about Flash you'll have everything NYC has to offer at your finger tips. The organizers of the conference know this and have created what they call the "City Track". They've organized a few "field trips" throughout the city that you can tag along with. Just think of all the cool stuff you'll be able to check out, eat, and do while you're here!

2. Its at the 3-Legged Dog Art & Technology Center
This place is just plain cool. Its entirely artist-run and have been supporting the arts in NYC since the center was built in 2006 just three blocks south of the WTC site. Personally, it feels good to be supporting such an organization.

3. The ridiculously good list of attending speakers
ZOMG! Srsly u guys! There hasn't been a large Flash conference in NYC...since...I don't know...2004? And that one pretty much sucked. But just look at the list of speakers! If you don't recognize the names, just trust me on this. They're are some really sharp people speaking about some great developments in the industry.

4. The Price is Right
Tickets right now are $299 (but lets just be real and say $300). In comparison to other conferences, this is CHEAP, especially for NYC standards.  And if you keep your ear in the community (Twitter, blogs, etc), you might even be able to find a coupon code!

I'd say these are my main reasons for anyone to attend the conference right now. I'm sure I'll come up with more and if I do, I'll update this post. Naturally, I plan on attending seeing as I live here and I hope to see you along with my other friends and colleagues here as well! It's gonna be a blast.

Upon downloading Sprint 8 I was immediately happy with the renaming of the framework event classes. They make much more sense now. Seeking progressive videos seemed to have improved as well, but I was still experiencing some buggy behavior when continuously scrubbing a progressive video.

My conclusion is that there is a bug in the NetStreamPlayTrait class and NetStreamTimeTrait classes. Basically, the NetStream.Play.Stop status code is sometimes dispatched when it shouldn't be. For instance, when I continuously scrub a video using the seek() method, there are times at which the aforementioned status code is dispatched when the playhead isn't at the very end of the video. More specifically, when I scrub to the end of the video for the first time the status code is dispatched and caught by the mentioned framework classes. Thus, this causes two things to happen.

First, the NetStreamTimeTrait class dispatches a TimeEvent.DURATION_REACHED event whenever this status code is received. Thus, the MediaPlayer redispatches this event at times when the playhead is not at the end, causing registered listeners to think the playback has completed when it hasn't. This was very strange, so I put some trace statements in the onNetStatus event handler of this class to check the currentTime and duration properties. When this event was dispatched during continuous scrubbing these values were never the same and often not close to being equal at all. Even when the video reached the duration during playback, these values weren't always equal. In one case the currentTime property was larger than the duration by one decimal place. I'm guessing this is a discrepancy between the NetStream.time property and the value of the duration provided by the meta data. At any rate, I thought it might be good to add a condition into the status handler to check if the currentTime was equal to the duration, thus verifying the playhead has in fact truly reached the end of the video. First, I edited the currentTime setter to look like this:

override public function get currentTime():Number
{
    return Math.min( duration, netStream.time );
}

This ensures that the currentTime is never larger than the duration and avoids the bug I described earlier. Next I added a condition into the onNetStatus handler of the NetStream.Play.Stop code. It now looks like this:

private function onNetStatus(event:NetStatusEvent):void
{
    switch (event.info.code)
    {
        case NetStreamCodes.NETSTREAM_PLAY_STOP:
            // For progressive,	NetStream.Play.Stop means the duration
            // was reached.  But this isn't fired for streaming.
            if (NetStreamUtils.isRTMPResource(resource) == false &&
                currentTime == duration)
            {
                processDurationReached();
            }
            break;
    }
}

Notice the additional condition to check if the currentTime is equal to the duration. This ensures that the TimeEvent.DURATION_REACHED event isn't dispatched until the playhead time has reached the duration. These two fixes took care of the TimeEvent.DURATION_REACHED event from being dispatched when it shouldn't be, however I was still experiencing a problem when I tried to resume playback of the progressive video if I happened to scrub it to the end.

Just as in the NetStreamTimeTrait class, the NetStreamPlayTrait class handles the NetStream.Play.Stop status code. As mentioned, the status code tends to get dispatched when it shouldn't, especially when continuously scrubbing and you happen to scrub to the end of the video. So, in the NetStreamPlayTrait class is that when this status code is dispatched, the following code is executed:

case NetStreamCodes.NETSTREAM_PLAY_STOP:
    // Fired when streaming connections buffer, but also when
    // progressive connections finish.  In the latter case, we
    // halt playback.
    if (urlResource != null &&
        NetStreamUtils.isRTMPStream(urlResource.url) == false)
    {
        // Explicitly stop to prevent the stream from restarting on seek();
        streamStarted = false;
        stop();
    }
    break;

So for progressive videos, the streamStarted property is set to false and the video is stopped. Confused, I followed the stop method around and determined that is just pauses the NetStream object. Then I looked around for where the streamStarted property is used and found it being used within the processPlayStateChange() method. From what I can tell it's used to denote if stream/video data exists in the NetStream object. Why would this be set to false for a progressive video's NetStream.Play.Stop status? Is not the video data still in memory? So I commented out that line and the code now looks like this:

case NetStreamCodes.NETSTREAM_PLAY_STOP:
    // Fired when streaming connections buffer, but also when
    // progressive connections finish.  In the latter case, we
    // halt playback.
    if (urlResource != null &&
        NetStreamUtils.isRTMPStream(urlResource.url) == false)
    {
        // Explicitly stop to prevent the stream from restarting on seek();
        //streamStarted = false;
        stop();
    }
    break;

Upon testing my video player my continuous scrubbing seems to behave properly! Woohoo! Now let me just say that I have not tested this extensively and I know that OSMF is still in development. I could very well have created a new bug by doing this, but at least things are behaving the way I would assume they would now.

Having some experience with PureMVC and even having some pleasant success with it, I was quite intrigued by some claims that robotlegs is "PureMVC done right". Hmm...At any rate, I can't help but be intrigued by a claim such as this and I always enjoy looking reading about developers' often unwavering opinions about how an MVC pattern should be implemented. So after reading the docs, development forums and checking out the examples, I feel that robotlegs is a great concept and has fulfilled its development philosophy very well. It seems to me that its primary focus has been the use of dependency injection. This allows you to keep the layers of your application nicely decoupled. In my early research, I was a bit annoyed by the fact that the injection module, SwiftSuspenders, was only compatible with the mxmlc compiler. However, the latest version includes the ability to use XML to configure the injection points so I can now use it with the Flash IDE. Yes, I, and a lot of other people, still use the Flash IDE to compile applications.

My only complaint about Robotlegs is very subjective. And let me preface this with the fact that I'm not a classically trained developer (I have a degree in design, not computer science). But Robotlegs was rather difficult to get my head partially wrapped around. More specifically, dependency injection was, and still is, rather difficult for me to understand. I understand the point of it, but how its implemented in Robotlegs still seems like magic to me. And because I don't understand the dependency injection all that well, its hard for me to feel really comfortable using the framework to develop anything. In comparison, what I really like about PureMVC was that it was pretty easy to learn and the core concepts are also easy to understand (at least to me). Regardless, this is not to say that Robotlegs is any better or worse than PureMVC.

Unlike my apprehensiveness for Robotlegs, I am really excited about Robert Penner's Signals project. I stumbled across this project while researching Robotlegs. I didn't quite understand it at first, but after checking out the source and giving a go I became instantly hooked on the idea and hope I can integrate it into my future projects. Basically what Penner has done is create an event/notification system that can pass around strongly typed objects to listeners instead of the native/traditional Event object. Signals are, to put it simply, an object that represents an event. Thus a signal object has its own API for registering and unregistering listeners. Signals also gives you the ability to define the types of signals an object should possess in your interfaces. This fulfills one of my biggest wishes for interfaces: a way to define the types of events an object should have to dispatch. As of now the project seems to still be in development with Penner experimenting how to make working with native events a bit easier. I highly recommend looking into his work, but don't expect much as he's apparently in Thailand until the beginning of January.

I'd like to donate them to a High School or College. Would anyone in academia like a Chinese or Spanish translated copy of our book? I'd prefer to hear from people who instruct New Media or IT courses, or is involved with a school's library.

I will only ship these to a school address. No home addresses. No student dorms and housing. Please email me at aircmr "@" nobien.net.

At any rate, after much debate we decided that the experience was a bit more important to us so we would focus on the Flash front end. Regardless of that decision, we also would create a text-only/HTML/SEO friendly version of the site for search engines to crawl using SWFAddress's SEO setup that uses a little special JavaScript, Apache's mod_rewrite and PHP. If you haven't checked this out yet, I highly recommend it.

If you're too lazy to go check out the SWFAddress site, I'll summarize what it does for you. Essentially, with the combination of the aforementioned technologies, SWFAddress now ships with a simple rule-based URL rewriting engine to handle entry URLs that do not contain the SWFAddress hash mark (#). This allows us to display equivalent content under the same folder structure that the Flash site/app uses for users that do not have both JavaScript and the Flash Player. For example, if you have JavaScript enabled and the Flash Player installed and go to www.umbro.com/en_UK/about/ you will be redirected to the SWFAddress/Flash friendly URL www.umbro.com/en_UK/#/about/. If you don't have JavaScript enabled or the Flash Player installed at all, mod_rewrite sends the folder path as a string to a PHP script. In this script you setup rules that determine what HTML content to display. Thus, you can display equivalent textual/semantic/SEO friendly content to anything that doesn't use JavaScript and Flash, eg: search engine spiders.

The only drawback I can see with this implementation at this point is the way in which users share URLs with each other. I'm guessing most users are more apt to simply copy and paste the URL from their browser's address bar than anything else. In this case they're grabbing the SWFAddress/Flash friendly URL with the hash (#) mark in it. Unfortunately if this is the URL that gets posted around the internet and shared via blogs, twitter, facebook, etc, then these pages aren't really going to increase in page rank all that much. However, in order to facilitate the sharing of the non-hash-marked URL, we've placed a "Share This" tool on as many pages within the Flash app as possible. This button uses the link sharing API's for a few social networks and passes in the SEO friendly URLs (without the hash mark) instead of whats in the address bar.

One thing I will say if you do decide to use this approach is to be aware of the amount of extra work that it will entail. You're essentially creating two sites, one in HTML and one in Flash. This can become rather time consuming depending on the scope fo the project and the amount of content. In the case of umbro.com we didn't really have that many pages to duplicate but we did have four markets/languages. On top of this, we initially created very bare-bones and unstyled HTML content that we knew would get indexed as long as it was being spidered. However, once a few people checked out umbro.com on their mobile devices and noticed that the "mobile" version was different than the version they saw on the desktops or laptops, those people suddenly thought that they were indeed seeing THE "mobile" version, not the version that anyone or anything that doesn't have JavaScript and Flash will see. So suddenly we had to pretty up that content with some nice images and CSS styles which required a bit more work than we had anticipated from the start.

I'm pretty happy with how things turned out with umbro.com, if you do some obvious Google searches such as 'about umbro' or 'where to buy umbro' you can see that pages from umbro.com are appearing pretty high in the results right now and thats honestly good enough for me at this point as I've never built an entire site in Flash and had any sort of results show up in Google before. I'm also pretty curious as to who else out there has implemented this with good results, so if you or any other sites you know of that have gone with this solution please leave a comment and URL. Thanks in advance.