Contents

• Introduction – What and Why MIX?
• Conference Grounds – Where was MIX and how did it go down
• DoubleClick – Syndication ready Silverlight
• Have we seen this before? – “Dude, Flash did that years ago.”
• Silverlight Adaptive Streaming – Curious about how the buffering works.
• Silverlight on Mobile – Same problems as Flash Lite has.
• Silverlight for Flash Developers – I do Flash; can I do Silverlight?
• AOL’s Silverlight Email App – Enterprise Silverlight
• Bloggers Mingling – A-list bloggers, and who I met
• Conclusions – What I took away from MIX.
• History Repeating – Some of the .NET crew is doing what the Java crew already did.
• Force Fed Silverlight – Silverlight is an alternative, not a choice.

Introduction

I was invited to attend the Microsoft MIX 2008 conference. After discussing this years conferences as well as the technology involved with my CTO, he decided we should go together. We headed to Las Vegas, where the conference was held, with the sole goal of evaluating Silverlight for use in our self-service video platform, one of our company’s main products I work on.

Although a lot our focus nowadays is on Flash video, we have a significant amount of money and technology invested in Windows Media. We also do way more Windows Media business, especially in the fun Live events arena. We currently create a lot of custom Flash video players that interface with our back-end video CMS system. Some are simple while others are full blown multimedia applications.

Can we do the same with Silverlight 2?

That was the fundamental question to answer, or have answered, at MIX.

Conference Grounds

I’d been to the Venetian Hotel in Vegas before for Macromedia’s / Adobe’s MAX 2006. The MIX conference had about 1000 less attendees than MAX 2k6 (2000+), but was no less grand. You could spot the geeks everywhere, and they seemed to outnumber the suits. Registration was simple, our hotel accommodations were great, and the facilities and layout were a lot more informal that I originally expected. I had this expectation of Microsoft being stodgy, formal, and just overall “proper like”. This was smashed when I visited the HQ in Janurary and met Bill Gates in person, but apparently that experience wasn’t enough.

The conference, however, felt a lot like MAX. It definitely was a fun multimedia event with code. My CTO and I made a decent attempt to talk to a variety of conference goers, not just Adobe & Microsoft employee’s. My interest was solely to identify what their background was, why they were at MIX, and what they hoped to get out of it. That, and I like meeting new people, especially people outside of the Adobe sphere who do software for a living.

Identifying a technology’s validity are based halfway on the technology’s merits. The other half comes from identifying the community around the technology, and seeing if the 2 have a future together. Do they mesh? If not, is that a big deal? Is there even an identifiable community? How does it compare to other technology communities that I’m familiar with? What are the pain points, and what are the great matches?

All of these questions I was continually asking myself quietly as I listened to speakers, both official and informal.

Keynote Day 1: DoubleClick

The were a couple things that I found interesting about the keynote.

The first was Ari Paparo from DoubleClick. Scott Guthrie, Corporate Vice President in the Developer division at Microsoft, was talking about some of the Ad features in Visual Studio. I had Twittered how irrelevant this stuff is in the media industry. If Silverlight had any chance of making a dent in what Flash is doing, it needed to integrate with a real ad platform, like say,DoubleClick.

Not 5 seconds had I twittered that, Scott Guthrie had a witty introduction to Ari who showed a brief overview of the SDK of using DoubleClick with Silverlight. For those who don’t know, DoubleClick is one of the largest ad platform providers. I think last week in fact, the FCC approved Google‘s acquisition of them. One of many, we utilize DoubleClick at work to allow customers to have relevant video & image ads to show in their video players, allowing them to monetize their content.

Getting an ActionScript 3, heck even an mxmlc (Flex‘s compiler) compatible version from them has been like pulling teeth. While frustrating, what was more frustrating was the lack of ANY Silverlight information a few months ago. Our first project utilizing Silverlight, used primarily as a solution for Mac users since Flip4Mac is noble, but flaky. One of the things that eventually forced our Silverlight player to be removed, replaced by Windows Media, and thus flipping the bird to Mac users was the lack of official DoubleClick support. It’s joke really since both Windows Media and Silverlight take the same ASX play list file (text file with a bunch of URL’s to media basically).

Now, it’s official; they can play ball in the online media & syndication world.

Keynote Day 1: “We” Have/Haven’t Seen This Before

The second thing that really jumped out at me was a lot of the Silverlight content shown that could of been done in Flash, or had already been done years ago. It was extremely frustrating to here the “oohs” and “aaaahs” from the crowd. I’m like, “Have you all actually used the Internet in the past 5 years?”.

You couldn’t deny it, though. There was a subtle vibe. I looked around the crowd and saw muted discussion as each Silverlight application was shown. Whatever negative thoughts I had clearly were not shared by the majority. There was muted discussions amongst co-workers. People sitting next to each other were in quiet, yet excited conversation. Clearly they had ideas about how to utilize the technology and wanted to act on them.

As Ryan Stewart said, “This crowd isn’t just familiar with our technology”. Ryan’s typical & positive Care Bear Stare attitude did nothing to sway my feelings. I call bs ; this has nothing to do with technology familiarity and everything with technology approachability. The Microsoft crowd DID and DOES know about Flash & Flex, at least some. The only reason it was apparently invalid in their eyes is that it didn’t integrate with Visual Studio & .NET easily, and wasn’t presented as a valid business case by Microsoft. That has to be it. There is no way the thousands of competent developers and designers there had no clue these abilities couldn’t be done pre-Silverlight Beta 1 in Flash or Flex.

Keynote Day 1: Silverlight Adaptive Streaming

Everyone thought it was really rad. I yawned. While down-graded on-t3h-fly streams has always been a touted feature of Windows Media, especially over Flash Media Server, I’ve never seen it work… at least at my place of employment. Additionally, if you have enough bandwidth to down-grade streams on the fly from 500k to 100k, you’re clearly running on a network that has issues. You’re best bet in this case is not to spend an inordinate amount of time trying to be clever and preload lower bit-rate streams into the buffer. Instead, just feed them a 100k stream, and call it a day. Disagree? Works for YouTube, so…

Even Flash Player’s double-buffering has left me not impressed on uber-slow speed connections. Besides, the graph they showed was VERY well designed, making me question the validity of every image thenceforth I was shown. Bottom line: I’ll need to play with it on a production environment to really believe it has any value. With most broadband customers, decent double-buffering prevents all problems with On Video & 24/7 video.

There is a company out there that has a comparable solution for Flash, but that’s for another blog entry. This does add ammo that Adaptive Streaming is valid, and thus usable.

Keynote Day 1: Silverlight on Mobile

It doesn’t really matter if it works, nor if they formed a partnership with Nokia. I’m American, and as such, my country is held in the grip of operators who have walled gardens. Meaning, I get tons Flex & Flash work, but only received 2 Flash Lite job offers in 2007. Flash Lite is not popular here for the same reasons Silverlight won’t be.

Windows Mobile and CE have always been good. I had Flash 6 running well back in 2003 on a Windows Mobile device. Logically, one could assume Silverlight would work just as well. At that point, though, I’d much rather utilize WPF, not Silverlight… unless the content was already created, and you’re merely porting, but that’s never how I’ve seen it work.

Sessions: Silverlight for Flash Developers

Not the exact session name, but close enough. I sat in for half of this; I believe one of blokes from Cynergy Systems was presenting. In the 40 minutes that I caught, he went over the API and how you can code Silverlight without using Blend just like you can code Flash without using the Timeline.

It was really uncool to see, even in C#, that working with XAML via code is still a bitch. Some could argue that it’s nice to have such low-level access to XAML via code. The presenter did the same thing in C# that I did in JavaScript in Silverlight 1.0: Abstract everything you normally do with GUI objects in a base class to act like the nice API of Flash.

So, instead of guiObject.SetValue(“Canvas.Left”, 30), you instead make a base class do that as a getter / setter, so you can instead go guiObject.x = 30. Lame.

I’m not sure if the new GUI components fix this. While boilerplate access can be fun if you’re an uber-geek, high level abstraction into easy to use components allow you to get stuff done. Just ask Simeon and his adventures in not-using the Flex SDK, instead trying various pure AS3 approaches.

What was nice, though, was that clearly XAML & C# are definitely do-able by traditional Flash devs. You’ll do the same thing that you did learning Flex & AS3: Learning the new tool(s) and learning the new API.

Although the Adobe CS3 installation process is horrible (not Flex), I’m pretty sure the Visual Studio + Blend is worse, especially for the beta bits based on mourning Twits I read. You’ve been warned.

Sessions: AOL’s Silverlight Email Application

The only true Enterprise application I saw during the keynote was AOL‘s email application. A whopping 10-billion alarm bells went off when I saw it for a few reasons.

First, I’ve had the pleasure of working with & meeting one of AOL’s good acquisitions. They are a smart, talented team who’ve already had proven results. That doesn’t mean that all of AOL is, but it certainly gives me the impression those who are doing the acquisitions know what they are doing. Second, the AJAX version of their email client was really fast and seemed to work great.

You have a perfectly well and good AJAX email client… why in the heck did you make a Silverlight version? I made a note to attend this session to find out. I got my answer at the end during questions. Someone asked did you look at Flash as an option (he should of said Flex, but whatever). They responded with “Microsoft Partnership”. That’s all I needed to know. It was nice to know that they had an existing .NET team that already knew C#… whatever. Programming is programming. C#, AS3… if you can code, you can learn another language and platform.

However, this session overall was enlightening as to what Silverlight developers perceive they need. Aka, all the stuff the Flex SDK already has. Keep in mind, they built this while Silverlight 2 was still in early development, so I don’t think they had any access to the controls.

That’s right, they had build their own component framework. $10 bucks says they spent 6 months just building the component infrastructure they needed to actually build an application.

What they DID go over were high level & low level details of each of the facets of their development. This was the really cool part. They built their own component base classes, and controls. They built their own measurement engine. They built their own skinning engine (read run-time skinning, not just Blend). Basically, anything you’d find in the bowls of UIComponent in the Flex SDK and all of his helper classes, they did some of that on some level. In short, a TON of work just to get started. Very impressive from a developer perspective, very crazy from a “how much R&D money did this team actually get from Microsoft, ZOMG!!!1111”.

Hopefully, other teams won’t have to do that much work assuming the components, both Microsoft’s and all the 3rd party ones I’ve seen advertised, do a lot of this already.

It was pretty annoying to debate quietly with my CTO in the audience. “Dude, they have AbstractClass as a keyword.”

“What, AS3 doesn’t have that?”

“No dude… you just add an Abstract prefix and follow the convention.”

*grumble* *grumble*

“Dude, Silverlight has threads?”

“What, Flash Player doesn’t have threads?”

“OMG, you don’t NEED threads to produce a nice, working Enterprise application.”

“I can’t believe Flash Player doesn’t have threads.” *grumble* *grumble*

In conclusion, I was very impressed with what the AOL team had done. I was also impressed that Silverlight 2 Beta 1 is already creating this level of applications. “This level” will have be carefully scrutinized; I did not get a chance to play with the real application to see how it felt compared to Gmail, Gooey, etc. The AOL team also didn’t discuss their battle scars. I love Flex & Flash, but even I have tons of battle scars to talk about.

Bizzness

I managed to tag along on 2 business meetings my CTO had with 2 cool companies. Can’t really say who they were, but can say they are relevant to my business: online video. Totally out of my element, so naturally it was fun to learn how those things go down. One was all formal with the pretense of informality, and the other was just an introduction to get to know each other.

It’s more likely for these things to happen since everyone is more likely to be at the same place at a conference like MIX.

BlogZone MIXer

I got invited to the BlogZone MIXer; a who’s who of the blogsphere. I brought my CTO along to this A-List event. There, your usual celebrities like Robert Scoble, Molly Holzschlag, Eric Zocher, Ryan Stewart, etc. The one dude I really got to have interesting conversations that I never finished was Alex Russell. Among other things, he’s one of the creators of Dojo, the Open Source DHTML toolkit written in JavaScript that helps abstract browser incompatibilities. Anyone who does JavaScript for a living is a prime target for my wrath. Unfortunately, he was really cool so I found it really hard to take the piss out of him.

I drilled him about his role on the “Board”. You know, the ones who are shaping the future of JavaScript 2. I tried to get as much dirt as possible since I only ever hear mostly positive things which I know can’t be right. As central a role as JavaScript plays on the web today, you KNOW there is some drama up in that mug.

Alex is bright. Regardless of the historical reasons of how he got on the Board, if you ever have some spare positive karma, be sure to throw it his way. Encourage him to keep fighting the good fight, to battle cynicism, and to never give in. He’s clearly qualified. He’s got some good ideas that apparently are shared by others.

Like all standards boards, I felt like some of the non-vendors give a flip for the implementers. For example, Object.prototype was a great idea, but I’ve yet to see a tool that helps you identify who’s mixing what on your prototypes. Who’s fault is that? Those who built tools like Adobe Flash or those who built the language and didn’t give an easy way in the language for tool makers to latch onto? It’s pure speculation; we didn’t get to finish our 3 concurrent conversations so maybe they do communicate each other’s concerns and I’m just not seeing it. I’ve read like 1 blog entry on Colin Moock’s blog with a summary of the action. After talking to Alex, I’m glad that’s all I’ve read, and that people like Alex are in there.

Hang in there, buddy!

Conclusions

I had a good time at MIX and definitely plan on speaking next year. Not sure on what yet, but it doesn’t matter. I’m really appreciative of Microsoft for inviting me. I loathe Vegas, yet really dug the event and how everything was put together. I felt their execution was good, and the topics relevant. There were also a lot of cool & intelligent people there, which is the most important part of conferences for me. Also, thanks to Cynergy Systems (I believe it was them) for the Tao party. Had a lot of fun there.

Blend and Visual Studio still look appealing and valid, but I’m not looking forward to my first Silverlight project mainly because I’ll probably spend yet another 3 days getting up and running again. The install requirements as well as required times are just insane. Flex Builder 3 takes 40 minutes to download on DSL, and 5 minutes to install and configure. The Eclipse plug-in + various JRE’s can definitely take up a lot of your day, but not days plural. In all fairness, it IS still a ton of beta bits working together. Maybe it’ll be decent by launch.

…did I mention I’ll have to do Bootcamp or Parallels since Microsoft doesn’t appear to have any plans for supporting Silverlight development on my Mac, just debugging? My PC at home will be fine since I’ve got tons of alpha and beta bits working (somewhat, *ahem*) on it.

I can see why .NET dudes are so excited about Silverlight. The coding style and language look a lot like regular .NET development. I don’t do .NET, nor do I do server-side development, but I’ve debugged .NET code other people wrote in the past and the learning curve will hopefully be just API and runtime features since it’s C#.

…and that’s the confusing part. What is .NET 3.5 now… 48 megs or so? Let’s just pretend it’s near there. Silverlight 2.0 probably won’t cap 4 megs (unofficial cap based on rumor from one WPF project manager I talked to). What of .NET is missing based on those 44 megs NOT being in the Silverlight plug-in? What of XAML isn’t supported? What of C#’s features aren’t supported? VB, JPython, JRuby ? Those are questions I need to answer to see how well their execution of making it easy for existing .NET developers to transition.

History Repeating

The most important thing for me that I took away from MIX was that I’ve seen this before. Flash Developers had an awesome multimedia platform to build upon for years. Java guys came, and then left. A few masochists stuck around really helping the community, and growth of the platform, out a lot.

Years later, Flex came out, and changed everything. Java devs came in droves. Then came PHP guys, Python, you name it. Flex allowed traditional developers to succeed where they apparently could not before using Flash or various other open source alternatives like FAME, Flash Develop, or FDT, etc. After learning to code for years, I physically cannot go back to Flash to do large scale development. Therefore, I totally understand why traditional developers couldn’t fathom how to do large scale scale projects in Flash.

I’m seeing the same signs in the .NET world. It’s been 2 years+ on the new runtime in Flash Player 9. Building applications in Flex, both Enterprise as well as widgets, are now proven to work well. Aka, we have a great runtime and a great set of tools. I worked with a .NET team 5 years ago to do the front-end in Flash & HTML, and the back-end in .NET. The work flow was good enough. I know a lot of .NET guys who use Flex for the front end.

Yet the impression I got from the conference was that this side of .NET is unknown by a lot of people. Either that, or just that client side development in something other than server-side generated HTML/JS/CSS was, and is, possible.

I’m seeing the same signs. These traditional server-side .NET devs ask, “So, how do you handle session data?” …and then the cliche response we’ve read soo many times in the Flash & Flex world, “We’re a stateful client. There are no pages. This is an application.” “How do you store local data?” “So the middle tier no longer handles the rendering of the GUI?” etc., etc., etc. Some get frustrated. Most get excited, see the light, and start asking both themselves and their cohorts a multitude of questions how much better things could be.

2 years later, Flex is the poster child for Java developers. In 2010, will we be seeing signs of Silverlight being the standard for .NETerz?

Every word above this sentence is invalid until they get their plug-in installation correct. A lot of the Silverlight installs that were 1.0, and people upgraded to 1.1, is where the trouble started. Some of the plug-in detection code got confused, asking you to upgrade even though you were. Some of those affected blogged conflicting reports, causing confusion of what the real problem was.

This is exactly the opposite of what you want to happen. This is also one of the main reasons Macromedia Director‘s “Shockwave” Internet plug-in failed. I’d create something, upload it to my website, and my mom couldn’t view it because of plug-in installation issues. That’s a serious problem.

Flash didn’t have this problem. It just worked. For years. Silverlight the plug-in INCLUDING THE DEFAULT DETECTION CODE needs to just work. For years. If not, it’s doomed. “Doomed” not meaning in never being a viable solution, but rather, Microsoft will have to spend major PR money to compensate for the negative perception that plug-in installations gone awry will cause.

Force Fed Silverlight

What does this mean for Flex & Flash devs? If you’re a Flex dev… not much. We need to wait for someone to intelligently blog their experiences with not just the controls offered by Microsoft, but by the multitude of 3rd party developers.

If you’re a Flash dev in the agency world, you need to pay attention. Yes, please temper this with the fact that, even though it’s a week+ past, I was still at a Microsoft conference bombarded by marketing hoopla. Regardless, media work will come your way where a client will want Silverlight. This can either be because of a partnership, because the company already has a plethora of Windows Media content that cannot be cost-effectively converted to Flash, or because like most clients, they don’t care about the technology choice and therefore the decision was already made long before the requirements hit your PM’s desk.

I would HIGHLY suggest you get training in Blend in a official capacity if you’re job can fund it. If you’re bored, add Visual Studio to the mix as well. This will save a lot of frustration and a lot of time. Blend and Flash aren’t a lot a like when it comes to animation and work flow. Blend is NOT alien, however. You can learn it. I’ve seen a traditional designer use it (caveat, at Microsoft HQ) and was impressed at how fluidly he made things.

If you’re a Flash dev as a contractor, you can wait a few more months. I’ve gotten 1 Silverlight job and one WPF designer job in 2008. This compared to at least 1 Flex or Flash job a day, every day. Once Silverlight 2 gets out of beta, it may behoove you to at least be capable of compiling a simple app… say, drawing a circle to the screen in XAML and then making it clickable . Sounds simple enough, but you’d be surprised how much time that effort really can take. And as you know, time is money in the 1099 world. Hopefully it’ll take less time by launch to get up and running.

If you’re a Flash designer, you’ve actually got it pretty good. Blend and Design are not just for Silverlight development, but also for WPF development, aka rich desktop application development. This means that if you become familiar with the tools, you’ll suddenly have a lot of traditional .NET shops looking for “designers”. Not all, but more than are now. A lot of the .NET shops will be just as fine with 2 shades of gray as some of the small software shops using Flex. All that has to happen is to have upper management see a demo, recognize that their team is already “capable” of using their existing skills, and demand Silverlight. Someone who’s had experience, and has the budget, will request a proper designer / consultant be hired. The work flow between Design and Blend wasn’t that great for me, though. Probably because I’m a n00b. PNG FTW!

4 years ago, I choose to experiment in Flex, and eventually make it my full-time career. This was a choice I made. There were no job offers for Flex. Enterprises were still experimenting in Flex projects. Flashdevs loathed the Enterprise price tag and having the compiler be on the server. I didn’t care… I loved it! 4 years later, Flex is still rocking strong, and has a bright future.

Silverlight? The marketing machine at Microsoft is awesome. You don’t have a choice to learn Silverlight or not. You can choose not too, but companies WILL be utilizing the technology, some requesting it specifically. For the later, you can either cater to that, and take their money. …Or not, and find some effective way to sell them on Flex / Flash. In a sense, we’re being force fed Silverlight. Assuming things go well for Microsoft, I’m not “choosing” to be a Silverlight developer. Rather, I’m merely reacting to market conditions. Flex was easy… it was love at first sight. Silverlight? It looks fun if I actually had people to pay me do it, but Flex is more fun.

Either way, you can relax. Flash Player is still king, and there is still a lot more money to made for a long time.

In Director, everything you wanted to be on a depth had to have had something there originally, put there on the “score” (Director’s timeline). If you didn’t do this at author-time, you couldn’t swap things out on that depth. The attachMovie function in Flash was great because this didn’t matter; I had thousands of depths to play with; the sky was the limit!

I later learned the sky on _root had a limit; it was called the Settings Panel. Lakitu wouldn’t even go near that elevation. It didn’t matter though; creating new MovieClip’s allowed millions of depths that designers & coders never used; it was wonderful.

To be fair, you could abstract this stuff in Director. The crew over at Director-Online had at least 2 sprite engines that emulated what Flash did, with extra features. Furthermore, I couldn’t really appreciate this stuff back then anyway; I couldn’t even return values from functions. I just had functions set global variables. Class? Que? n00b.

I tried going back after I learned some things, but I just couldn’t do it. Flash offered too much. It was soo fast. So much more effective. ActionScript just seemed more organized than Lingo.

After getting over my frustration at AS1, I learned that I could create re-usable stuff. While I loved to re-invent the wheel ALL THE FRIKIN’ TIME, it did get tiring after awhile, especially when my 4th generation Scrollbar still lacked track clicking and scroll buttons. Creating re-usable tools was hot.

After getting over my furious frustration with AS2, and learning enough design patterns to pretend like I knew what I was doing, I slowly developed a loathing for AS1. I then had a hatred for anything not AS1; aka, code puked on frames.

I remember seeing a lot of creative things done with prototype in ActionScript 1, however, and even some still in AS2. So, I tried to go back, and experiment. I always ended up getting bit in the arse in the end.

When AS3 came out, the early version, it actually wasn’t that different (for me) from AS2. AddChild vs. createNewMovieClip, aka the new DisplayList was pretty easy. Protected vs. private, and other namespace features made sense pretty quickly too. The only hard thing was learning the immensely large new API. It’s one thing to remember that a CheckBox emits both a click AND a change event in the Flex SDK, and you need to care about the latter… it’s another to remember that navigateToURL is in the flash.utils.* package. Even the built-in stuff is immensely large.

What is interesting, though, is that I never developed a hatred for AS2. Because of the complete and utter lack of communication between the 2 AVM’s, combined with Flex’ slow rise to power meant a lot of parallel AS2 and AS3 work. If you asked me if I wanted to do an AS2 or AS3 project, I’d probably respond AS3, unless your deadline was a week or less.

…and that’s my point. Writing AS3 is slow. It’s finally reached a maturity as a programming language; a real language, not a “scripting language” because it now officially compiles to machine code on 3 differentchip sets. As a real language, it has all the features (most, hehe… private constructor what, abstract classes who?) a traditional programmer would expect from a programming language.

My boss, a professional Java Developer who now does a lot of PHP (and I’m sure has a larger illustrious career I don’t know about yet), said that a strongly-typed language should be making me faster, not slower.

In shock and anger, I pulled my phone from my pocket, called up “Bullshit”, and requested he leap upon my bosses’ head.

There is a reason I click the “Flash” icon on my task bar, do File > New, hit F9, and test a new String parsing algorithm there in AS3 instead of going the ActionScript project route in Flex Builder… or even “new ActionScript File” and making it launching it as an Application. Flash is faster. Sure, once you get rolling, you can have some good test bed code combined with test cases even run by ANT in Flex. I’d still argue the instant gratification in Flash beats Flex.

…but it doesn’t stop there. I mean, after hearing about things such as “int promotion” and “compiler optimizations based on clear, strongly-typed variables”, AS3 can get out of control. Parsing a pipe (|) delimited string, properties separated by commas (,), with name value pairs separated by equal signs (=) has gone from 15 lines in pre AS1 to 40 in AS3 if you ensure every parsed variable is strongly typed. For an algorithm that’s only run one time very rarely, AS3 doesn’t really benefit here.

Fine? Then why not NOT strongly type so much? Only strongly-type to ensure you don’t get any type casting exceptions, and move on with life?

…because… I … can’t. It’s hard to stop. I’ve been trained by the fear of the software engineer army to strongly-type everything. To ensure the compiler has a crystal clear understanding of everything, and that my code will run at moch-10. I can have faith that the old AVM will never even need gas, because the key in the ignition for it will never be turned. All the code I write now ensures everything is typed, and all namespaces are correct.

I’ve tried abandoning namespaces and using *, Object, and even just abandoning type-casting in general for quick tests or prototypes. It’s just as time goes on, I find the code I add to those things starts getting more AS3 like.

Bottom line, it’s really really hard to break the habit. Every time I go back to AS2 for some random project, I’m reminded how damn fast it is to create things in it. Half the exceptions I get in AS3 I really don’t care about, and don’t need to know about; they don’t impact the project from working if they are small in scope. A lot of my data is either primitives or simply arrays.

For smaller projects, AS2 is still the bomb. For smaller algorithms, less strong-typing just results in less, more readable code.

I can see why professional Ruby, JavaScript, and Python developers still exist. I don’t care what anyone says, loosely typed scripting languages still kick ass. While I wish their engines weren’t so damn slow for larger projects, lately, I’ve just been finding that for a lot of smaller scoped projects or areas, I’m glad I have the loosely typed option.

While I fully believe the majority of the industry will use C# for Silverlight 1.1 going forward, MAN was it refreshing to write it in JavaScript for 1.0. Taking a break from AS3’s strict ways was great. SmartFoxServer has an option similar to later builds of Red5. You can write in the standard Java for performance reasons OR in your scripting language of choice (JavaScript, Python, etc). For a lot of work, scripting languages are good enough, and since they are good enough, you can write less code, faster to get the same result. That last part is debatable, but not by me. After having a career in both, to me they both clearly have their place.

…what I can’t figure out is how to drop the “good habits” that AS3 teaches you to go back to fast and furious ways of scripting languages.

Had the honor of meeting up with an old friend yesterday. Chris Skogen, one of the talented gents at Gizmolabs, was my manager & tech lead when I worked at BellSouth. He’s an extremely talented programmer, doing a lot of C, C++, assembly, and Java. Below is some of his team’s coding + hardware work in action. This is not actually the record music playing, but rather, the record’s time code being used to scrub an MP3. Plethora of other features but… isn’t this one alone enough to make you go, “OMFG!!!”

He’s been doing it for a long time, and since I respect anyone who has a lot of experience in this industry, I pretty much spent the day absorbing every word. We were supposed to meet for lunch since her majesty and I skipped out on going to a Christmas party of a friend of his that we RSVP’d too. Figured, I could buy him lunch and he’d forgive me. Anyway, instead of staying an hour at noon, stayed till 7pm mainly talking shop, finishing with Gears of War coop. He’s the guy that got me typing my brackets on a new line after he and another C coder at BellSouth started making fun of my if statements (Flex Builder is biased against this way of coding, btw…bleh !). He was also the guy who first introduced me to the Command pattern, and wondered if the Flash community had any framework like that. Four months later, I was all into ARP, which has the Command pattern as its central crux.

I spent some of the time asking about invalidation methods. Invalidation being defined as “painting the screen with pixels in an efficient manner”, also known as redraw. Since he develops for multiple platforms, he knows the libraries and strategies involved for screen redrawing on Linux, OSX, Windows, and various devices. I remember one of Bruce Epstein’s books, Director in a Nutshell describing “The Great White Flash”. It’s been so long I can’t really remember the cause, but the redraw of the window caused the application to start with this white flash, basically a redraw of the screen that sabotaged the initial experience with various ways around it. When Chris would describe Windows redraw events compared to other platforms, it sounded all too familiar. The Director mantra back then was, “If you build it on PC, you know for a FACT it’ll work just fine on a Mac. If you develop on a Mac, it will NOT work on a PC.” A lot of the intricacies of when something redraws an area, how you have to manage it, etc. seemed really gross, and painful. However, like a lot of C guys I’ve talked to, he seemed to take it stride, view it as a conquered fiefdom, and begin to relay the double-buffering strategy employed in some cross platform library. Must… get… that… attitude!!!!

In particular, I recently had the good fortune of getting Greg Burch’s, bloke employed at Adobe on the Mobile Team, feedback on my Flash Lite 2 component set. The guy clearly knows his stuff, has massive knowledge in ActionScript optimization, and is very focused in achieving that goal. He also understands mobile GUI development as well as the experience users expect on devices. After talking to him on the phone, I can clearly see why he is employed with Adobe on the Mobile Team. In our discussions, both offline and on, he basically set out in the opposite direction as me. While I was originally interested in creating a nice API as a tertiary benefit to the original 3 goals, he instead approached it from a “we must make it lightweight”. Even 10 seconds of his recounting of past projects with no supportive details clearly indicates that he has earned in blood a lot of great techniques and understandings. Basically, he is making the code look as much like ActionScript 1 as possible (even C for that matter), not as an intention, just a result that optimization and ActionScript 2 & OOP do not go hand in hand. While he is confident and happy with these potential changes, I was somewhat disheartened. His suggestions all met the first goal of “if it runs Flash Lite 2, the framework needs to work”, but I felt it was losing a lot of it’s utility to developers; they would now have to do a lot more work (typing basically, and not all of it comfortable). However, if you are going to run under the insane CPU & RAM restraints, no one is left unscathed. Welcome to the suck.

After talking to Chris, however, he pretty much corroborated everything Greg was suggesting and had little empathy for my forlorn yearning for OOP. This lead to a very interesting discussion about inheritance vs. interfaces. He’s a big believer in programming by contract; having classes implement interfaces instead of using the extends keyword. After hearing him recount the challenges of being “a slave to the base class”, I totally understand and agree… for large scale projects with uber-knowledgeable individuals. If you are on a deadline, and have a variety of skill sets on your team, abstracting details seems to me like a good thing. I hate those projects, though,hehe! Flash Lite, however, has no room for interfaces as they too are basically objects like classes, and take up RAM. I digress I know, but it’s fun stuff.

Anyway, let me give some context first. There are multiple ways to redraw things to the screen in the Flash Player, with different repercussions in performance and developer approach. You basically have the following options in Flash Player 9:

1. DisplayList
2. Blitting
3. Drawing

Both blitting and drawing depend on the DisplayList, but they are not mutually exclusive. The DisplayList is the act of adding a graphic object to a list of “things to draw”. If the Flash Player see’s it in there, it’ll get drawn. You can remove the object from the list, and it’ll no longer be drawn. This has a lot of positive repercussions in that a graphical object can exist in RAM without taking up CPU resources being drawn. Flash Player 8 and below did not do this. If you created a graphical object, like a MovieClip for example, even if it was invisible, it would still take up system resources being drawn every frame.

Suddenly, the programmer now has control over what is drawn, and when. This makes coding easier, too, because you can choose when to draw things, therefore writing more scalable & efficient applications… just what Flex needed when you started writing these gigantor Enterprise apps that made Flash Player 7 & 8 scream in pain.

There is something, however, more efficient than the above. This is called blitting. It is the act of painting a bitmap to the screen. A Bitmap is a DisplayObject in Flash Player 9, meaning it can be painted, or not painted, to the screen at the developer’s discretion. While Flash Player 9 has removed the problem of “too many objects == too much system resources”, Bitmap never has this problem even if those objects are in the billions. This is because you only ever have 1 bitmap (usually) that you paint on top of. Therefore, you actually have multiple small objects in memory that are then redrawn at some interval to the screen, and ONLY those areas that have changed. This is actually what is probably under the hood of the Flash Player, written in C/C++, that is redrawing all of your DisplayObjects. However, if you know going in that you’ll have a lot of objects which aren’t interactive, blitting is a wonderful technique that scales well, uses less RAM than the DisplayObject , and CPU is minimal because Bitmaps don’t use a lot of CPU to redraw compared to vector graphics. This technique can be used in the Flash Player 8 as well, although, there is no DisplayList so even if the Bitmap isn’t being visibly shown, it is still taking up CPU cycles to redraw it. Both can be combined with double-buffering where you paint to an off-screen bitmap, and copy pixels onto a on screen, smaller one.

Finally, there is drawing. Drawing is the act of using the Flash Player’s vector drawing API to create vector graphics. These are wonderful in that the engine to create them is small, and they take next to no RAM. They look nice in terms of anti-aliasing, and the API is simple enough you can create some pretty sophisticated results by building atop that foundation. The downside is that drawing doesn’t scale very well. A lot of “anything” in Flash Player 8 and below used a lot of CPU, and vector content is definitely a prime candidate to use those resources. There are various techniques you can apply in Flash Player 8 and 9 using cacheAsBitmap, scrollRect, or even blitting the resulting drawing and thus removing the vector part.

The way each of the above is rendered is doing on an interval, called a “frame”. Flash Player was built originally as a vector to pixel renderer , and later incorporated a timeline to show changes in these images over time. In effect, a lightweight animation tool was the result, hence Flash Player’s rising popularity for design in the Internet during the modem, low bandwidth days. These frame ticks run on some developer / designer set time code, like “15 frames a second”, or “120 frames a second”.

What that means is that the Flash Player will update the screen 15 times a second, but more no more. It is not guaranteed to update the screen that many times for various reasons such as screen refresh, CPU usage, etc., but it IS guaranteed not to update more than the set frame rate. This is useful for animators to convey motion. As Ted Patrick has written about in the past, the introduction of the ActionScript Virtual Machine share’s this time between rendering. The important thing to understand, though, is that ActionScript for the most part is single-threaded. This means that once it starts, it doesn’t stop till it’s done running all of it’s code. If you have a lot of “stuff” happening when a user clicks a button, that code is run, and nothing else can really happen in the meantime. There are various threads that the Flash Player spawns to handle network operations, keep tabs to see if theAVM stopped responding for whatever reason, but none of these are accessible to the developer. Bottom line, if you’re code is busy doing things, you’ve allocated less time to the Flash Player graphics renderer to redraw the screen, and thus you’ll lose redraw fidelity.

How do you then lessen this impact, and create an effective invalidation solution given the technology?

In Flash MX and Flash MX 2004, an invalidation routine was created that ensured that components were only ever changed visually once per frame. This was done because while the developer was more than capable of changing a MovieClip‘s x and y coordinates on the screen multiple times in a few milliseconds, it would only actually render once. Changing those properties directly actually triggers a need to redraw event in the Player, and thus you are being very inefficient in your use of the Flash Player. To remove this problem, the first technique was a convention called drawing and invalidation. You would have a few private properties in a base class that abstracted MovieClip , and allowed you to change it’s properties with the ability to then invalidate on your own time. Some would invalidate immediately. It was a good first attempt, but was more formalized and better implemented when ActionScript 2 came onto the scene in Flash MX 2004. While AS2 still outputted the same bytecode as AS, it still implemented the main function that made this possible, introduced flexibly in Flash Player 6: onEnterFrame.

The enter frame event is something emitted every frame. In Flash Player 9, DisplayObjects do this regardless of whether something has a timeline or not, 1 frame or 10 billion such as MovieClip & Sprite. While the name itself is somewhat legacy, it is useful to understand what it really means. First, it is guaranteed to be fired once per frame. Unlike setInterval which can fire randomly (at most 10 times per frame, or less for longer intervals), you can depend on the onEnterFrame function to run when you expect it to run. When it actually fires within a frame context isn’t important. What is important to know is that it is synonymous with “redrawing now”. Since you can only redraw once per frame, it fits in nicely with knowing when you are best suited to do so effectively. FlashMX & Flash MX 2004 would use the invalidate method for graphical components. This meant, “redraw next frame”. So, the developer could change a bunch of properties, styles, etc. and theMovieClip wouldn’t actually redraw itself visually (by setting _x, _width, applying a color, etc.) until the next screen redrawn, no matter how many were changed, or how many times the same one was changed.

This was great in theory, but a lot of the race conditions with measurement and styles made it hard to effectively do. Regardless, it was THE best way to ensure effective redraw. This was slightly improved upon in the Flex 1.5 framework with a more formal system:
– set a property
– if it causes a redraw, invalidate a draw function, otherwise have that property’s dirty flag set
– if a dirty flag was set, determine what type of redraw to perform, a draw, size, measurement, or style change
– invalidate one of those functions if applicable
– one of the invalidated functions would run at the next redraw

This made possible larger Flash Player applications. The problem was, though, that even if things weren’t redrawing and just sitting there, they were still taking up resources, regardless of the wonderful invalidation implementation. Hence Flash Player 9’s DisplayList being invented.

Blitting is kind of a low-level, boilerplate affair, and it’s currently not used a lot by the Flex framework. This is a shame. While the Charting components and Flex components both make extensive use of caching as bitmap and setting effective scrollrects , I think for some of the non-interactive parts of charting, they could scale effectively better. I have not, however, read reports of problems with the charting components not scaling. Props to the power of ActionScript 3!

A significant amount of the framework is being drawn with vector graphics via the Drawing API, and all uses extensive use of theDisplayList.

So, returning to my invalidation implementation, I chose to use the Flex framework invalidation methodology in my implementation of a Flash Lite 2 component framework. Granted, I didn’t have the added or render event’s, but enter frame is all you really need. Seemed logical enough; you want something to efficiently redraw on a device that REALLY needs to be efficient. As I later found, some on my own, some with Greg’s help, there are a few problems with this.

1. Most dirty flags in the Flex framework start out with default values of false. This default value takes up RAM, RAM that I don’t have.
2. I am making an assumption that a developer wants to have the component redrawn when they change a property. This is an incorrect assumption to make.

Regarding #1, one solution is to simply not define default values for the dirty flags. The if ( flag == true ) still results in a correct evaluation if the default value is false, undefined, or null. That way, the flags would only last for 1 frame. Unfortunately, that is still a lot because Objects, what all data-types derive and thus extend in pre-AS3, take up a lot of overhead so even a Boolean has a valid cost to think about.

Regarding #2, there are numerous cases where data isn’t ready for consumption by GUI controls, or some other process hasn’t completed yet. Some of that data or relevant process may be needed to do internal calculations for redrawing. I’m slowly to see ways for developers to implement their own call to invalidate. So, instead of doing this:

attachMovie ( ComboBox.SYMBOL_NAME, “cb”, 0 );
cb.prompt = “– select a value –“;
cb.dataProvider = someArray;
cb.setClickHandler ( this, onClick );

You would instead do (per Greg):

attachMovie ( ComboBox.SYMBOL_NAME, “cb”, 0 );
cb.prompt = “– select a value –“;
cb.dataProvider = someArray;
cb.setClickHandler ( this, onClick );
cb.invalidate();

Notice the only difference is the addition of a invalidate method call. This triggers a redraw. The former, every single public property set, and some methods may trigger a redraw, usually via getter / setters (which have a lot of overhead…). Yes, it’s efficient in that it supports an infinite amount of property setting with only one redraw, but again, I’m assuming the developer WANTS to redraw. Maybe they have the data, want to set it, throw it away, but are awaiting more. Maybe they need the above, plus they are doing it to multiple controls over a sequence so they can effectively deliver a large amount of data through a small series of steps the device can handle. Later, they can then redraw when they deem it necessarey to do so.

In discussing this stratgedy with Chris, he’d recount a lot of techniques Apple’s Cocoa uses as well as some of his own implementations. He found the most successful (and I’m paraphrasing badly here) is when parents are responsible for drawing their children. This allows you can redraw just one section of the GUI, or if you need to redraw everything, you can call invalidate on the main parent, and it’ll cascade down the tree of children, who in turn call invalidate on their children.

What I find interesting is that this technique could not only work in Flash Lite 2 / 2.1 which is basically Flash Player 7, but also in blitting in Flash Player 8 as well as utilizing the DisplayObject API in Flash Player 9. In fact, it’d be really nice if Flex 3 gave us this option. I think the reason it’s not in Flex 2 is a lot of people need an accessible framework; meaning, low learning curve. Some people have never developed or programmed before, or not done that level of heavy GUI work, etc. Bottom line, I think the decision by the Flex team is “developers shouldn’t have to know how the Flash Player works to effectively write applications atop it”. I totally agree. I also believe, however, that there should be a way to optionally allow those of us who know what we’re doing to redraw when we see fit. It’d really help those larger applications, or when you are trying to squeeze all you can out of an implementation, say, Flash Lite 3 which could possibly use the new AVM on a device :: crosses fingers ::.

While it’s more work for the developer, I understand why Greg suggested what he did now, and have more context as to the ramifications what power this really gives developers. I guess I just don’t really have in my head best practices on implementing this. The abstracted invalidation model that Flex has removes any care, and provides a nice convention for me to build atop of. Now, I suddenly have to care when I redraw things which could be different for each GUI control. Furthermore, the less utility I add to a framework by making it more efficient instead, the more the expectations of the Flash Lite community shifts to wanting more features out of controls. Not sure the best approaches to either. Fun, regardless!

We learn about Director MX 2004 and all it has new to offer, and even before it’s begun,
your having the urge to fill Macromedia’s coffer.

Scarfing on pizza, downing mad soda,
I see familiar names from fellow designers and codah’z.

Now, I dig the DVD (ROM), I dig the external editing, the sprite & channel naming,
and the Stage that can dock while authoring.

But I think most what I dig, regardless of the slow bytecode, is the JavaScript Jingo,
implemented via open-source ECMA from Lingo.

I hope Java guys dig it, open source hounds try it out,
and a few Flashers do a round about… face.