Here is my take on the issue of Stage3D/Molehill. While reading related tweets and posts, I notice a few misconceptions about Molehill – and this is something I’d like to address here.

Dude, where is my Display List?

Right from the start I felt something doesn’t feel right. If all the demos are using engines like Away3D, what’s in it for ‘plain’ flash games? Apparently, Molehill (and Flash 11) does not include GPU hardware acceleration for the Display List.

First of all a note about architecture. Flash uses a retained mode rendering model, through its Display List. It means we don’t actually draw, we place display objects on the display list (and the stage) – the rest is done by the Flash player, where the drawing actually takes place on every frame.

In contrast, Moelhill API  is a thin wrapper for OpenGL  (or Direct3D in some cases) that provides low level drawing of 3D geometry and textures, including programmable shaders. It exists outside of the flash stage, almost as a standalone system. It is not designed to support, or implement drawing of display objects.

While not without its problems, the flash display list is the core feature of Flash: a simple and easy to use scene graph that gets processed and rendered on every frame. Its what makes Flash Flash: you would not want to imagine building any games or applications without it.

Catching up to current technologies

This year we started seeing GPU hardware acceleration in JavaScript/CSS, although not on all browsers. Browser have rendering engines that can accelerate primitive drawing for vectors and font when rasterizing them to canvas. I would expect no less from the flash player.
The days when non-accelerated Display List was sufficient for developers are over. Here is what Ben Garney, a flash game heavyweight, says on his blog:

[...] I use the display list for lots of things, just like any Flash developer. It’s a useful, flexible, and powerful tool.

But when I have specific, performance oriented needs, I ditch it in favor of something I can control completely. That’s why I always use a raster pipeline – drawing all my own pixels – for my game rendering. Using BitmapData.copyPixels has a consistent, reliable cost, whereas the cost of drawing a DisplayObject hierarchy, either on stage or via draw(), is highly variable and difficult to predict in terms of both memory and CPU consumption. [...]

So developers like Ben Garney are opting to write their own renderers in order to gain better performance, but that is not an ideal long term solution. A much better one would be to utilize both multi-threading and GPU hardware acceleration for the standard flash Display List.

Hello 1993

For me, this is Deja vu all over again. It brings memories of the early 90s, were all we had was raw OpenGL or DirectX, and programming 3D was considered a black magic, some sort of witchcraft. We had to use special bitmap fonts and skimp on UI features for games, because everything was done in low-level, with no component libraries to speak of.
A lot has changed since then, both in technologies and standards. Are we are expected to use the low level Molehill or use a Molehill based 3D engine for any plain old 2D project?

1993 Ford Mustang

Bringing GPU acceleration to a small subset of flash applications just won’t cut it. Casual games that make a large part of Flash projects, need fast performing 2D display as well as complex UI. Forcing developers to shoehorn Molehill into any 2D project is just wrong. It’s not a good solution and would push more Flash developers to jump ship and look for alternatives.

GPU Acceleration for All

Don’t get me wrong: I am a 3D enthusiast myself, and did a lot of 3D programming on different games way before I started using Flash – and 3D API in flash is better than none. I simply don’t like the idea of having to choose between hardware acceleration or the Display List and not both of them together.

The next logical step for Adobe would be to build GPU hardware acceleration into the Flash Display List, so that the bottleneck of scene rendering would be removed. Yes, it carries some risks since Flash would become dependent on display driver vendors to run consistently on different platforms, but surely this can be resolved by partnering with nVidia and AMD. If done correctly, any existing AS3 code would be accelerated without any changes.

How to make Facebook-AS3 API to actually work without going insane

Note that the last major change in the API was in April 2010 with the introduction of OAuth 2.0 in Facebook. At the time of this writing, version 1.6.1 is the current version of the API.

First, the setup for a web based project is a bit messy, since you need to register your Facebook app with a specific URL and put some code in the Html wrapper – for a full explanation read this post.

OAuth in AS3

Logging in a Facebook user with OAuth2 is simple enough if you use HTTP and JS. Issue a call with the AppID and permissions and it receive the access token in the JS callback function. Not so with the facebook-as3 API: you need to call Facebook.init() and then depending on the result call Facebook.login() to handle the login prompt.

Problem #1 - Facebook.init() returns (null, null)

The official documentation says Facebook.init will return a session on success and null on fail – however it actually returns only the session in the result, or null if you are not logged in. The second argument (fail object) is always null. Just this simple discovery had cost me a few days of hair pulling, so don’t rely on the docs. Yes, they are supposed to be updated frequently by Adobe but somehow this detail slipped out [facepalm].

Problem #2 –  Facebook.login() returns null regardless of actual login

Calling login right after Facebook.init() returns may not work as expected, and worse – results will vary depending on the browser and Flash player version (For me it works in Chrome and fails on IE8).

Don’t waste time on the official docs, since there is no mention of that there. It turns out that Flash player 10 imposes a security restriction (that may or may not be related to the browser) that will cause login to fail silently and return right away with null and lose connection with the login popup, which is very confusing since the API call to Facebook actually works in the browser, only not in your code [facepalm again].

My Solution

There is more than one solution to the authentication process, and it really depends on what you need. You could avoid the facebook-as3 library all together, as some developers on the forums suggested. There are no restrictions in HTTP/JS login, and it is painless. But what about the AS3 code?

After looking at a few samples, it appears that the simple solution would be to have a login button in your app, and require the user to click it to invoke the login popup. Simply put the Facebook.login call in the button handler function and it works perfectly.
However, you need to prevent subsequent calls to Facebook.login after a successful once, so make sure you hide or disable the button or face the consequences (I managed to crash IE8 with multiple login calls).  See sample code below:

	Facebook.init(APPID, onInit);
	...
 
	private function onInit(result:Object, fail:Object):void
	{
		btnLogin.visible = (result==null);
		if (result != null) {
			// We have a session
			trace("you are logged in");
		}
		else {
			trace("need to log in");
		}
	}
 
	// Login Button handler
	private function btnLogin_clickHandler(event:MouseEvent):void
	{
		Facebook.login(onLogin);
	}
 
	private function onLogin(result:Object, f:Object):void
	{
		if (result == null) trace("Access denied!!!");
		else {
			trace("Login complete.");
			btnLogin.enabled= false;
		}
	}

If anybody has a better solution I would love to hear.  Hopefully someone at Adobe will notice and modify the documentation to better reflect the reality, or even better – fix those issues inside the AS3 API so that it would be consistent with the HTTP/JS API.

Flash is still ahead of all the others

OK, so this ‘Flash is dead we all do HTML5 now’ argument is getting a bit tired, but the trend now is to offload simple projects to to traditional web tools – HTML, JavaScript, CSS and the like. I can only see good in that – clients would use their web developers for trivial web site projects, leaving stuff like games and complex animation for Flash programmers like myself. I say good riddance.

As already mentioned by Stefan Richter in “Why Flash will be fine“, the Flash platform has never been more popular. Adobe is finally focusing on making it better and faster and the Flash developer community has always been characterized by talented people who are passionate about their code and art.

I was really impressed with the new AIR 2.7 for iOS, and now seriously consider developing games for the iPad, something I could not even imagine a year ago. As Jesse Warden says in his blog,  there are lots of technology choices for developers, like iOS, Andriod native, Corona SDK and Unity3D to name a few, and there is plenty of room for everyone in todays market and no lack of opportunities.

But is lagging behind

My next related comment is on the promised features in Flash player 11, namely Molehill (or Stage3D) and worker threads. FP11 is now part of Adobe Flash incubation program and in public beta.
For years now, Flash developers, and game developers in particular, have struggled with the lack of two main features: hardware accelerated graphics and multi-threading. This is almost unthinkable: multicore processors have gone mainstream 5 or 6 years ago and we can’t utilize them. Graphic cards are popular for the last 15 years or so, but flash player still does all the rendering in software, on the CPU (with the exception of video).

I remember being excited about 3D back in 1998, while programming with OpenGL and DirectX. A lot has changed since then.  Take the XNA platform for example – it had all these features on version 1.0, back in 2006.

To say that this is long overdue would be an understatement. New features like 3D and multi-threading take time to sink in and mature, and since FP11 will only the first generation, who knows how many more releases it would take for Adobe to get it right.

In previous posts (Spark pains) I expressed my disappointment with Spark’s lack of functionality versus the Flex 3 mx components it came to replace. Like others, I shared the notion that Spark is half baked, and Adobe should have included a more complete solution in version 4.0 or 4.1, at least for the included components like button or image. Let’s see what is in for us in the upcoming Flex 4.5 (“Hero”).

Spark Button: The return of the Icon

Good news – the icon style is back to Spark button!  After spending a lot of time writing custom skins and specialized classes I was glad to see that the spark button now supports icon out of the box, just like the good old mx button. Too bad it came  late for my recent projects, all using spark buttons, cluttered with custom skins only to achieve the trivial task of putting an icon in a button.

By any reasonable standard, we should have had these  in Flex 4.0 release last year.

I can only reiterate the comment in a post in the Flex Examples blog: all that to get what we’ve had for years in Flex 3.  I really am glad these basic features are back, but was it really necessary to wait over a year to have it back (and require Flash 10.2 player)?

Really, Adobe – is that too much to expect?

Spark Bitmap Image

Another source of frustration for me was the spark BitmapImage. Made to replace mx image, it gave similar functionality… well, almost. No support for runtime loading and display of timeline swfs forced me and my team to fall-back to mx image for no other alternative.

Even worse, the overblown security model made image caching almost impossible to implement. Try constantly loading images from services like flikr and facebook and see what I mean. Policy files, trusted or untrusted domains, nothing seems to work properly. To actually make it possible to access bitmapData, everyone uses a PHP script to bypass the flash player security model – not very elegant.

A Hero to the rescue, Flex 4.5 brings the new and improved  BitmapImage with all of mx image features and built it image caching – Hallelujah!  they even threw in smart scaling and letterbox mode.  It’s too soon to comment on how effective it is since it is still in beta, but kudos to Adobe for doing the right thing.

What more can I say? Better late than never.