Molehill and the DisplayList – A Step Back?

There has been a lot of buzz about  Molehill (or Stage3D) and GPU hardware acceleration in the upcoming Flash player 11. However, very little was said on the practical aspects on normal flash applications and games.  Now that the public beta is out, we can get a feel of what it really is, and see what you can and cannot do with it.

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.


With Flash 11.x and the introduction of Starling, there has been an huge leap to fill in the gap for the 2D display. Frameworks like Gnome2D, ND2D and Starling are becoming popular and widely used in mobile and web projects, so the issue of hardware accelerated 2D support is mostly resolved. For more on that , see my post Catching up with AIR Mobile.


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.


3 thoughts on “Molehill and the DisplayList – A Step Back?

  1. I’ve been playing with Molehill, and there’s nothing keeping you from doing both. You can create a 3D object in the background and still use the display list for all your text boxes and menus. I’m not sure on the specifics, but it seems like the display list is processed using the CPU while the 3D calculations are shipped off to the GPU. I’d also love the display-list acceleration, but the current setup seems like a great intermediate step.

  2. @Aaron
    Well the problem is that the order that the draw order is stageVideo->stage3d->displayList . I can’t even have a stage3d element in the displayList, so I can’t use stage3d in an application. How can I use stage3d with my application, while still using the Application panel, Panels, Tabbed Navigators etc? I can’t really use both. I can stick some components on top of the stage3d, but that’s not the same thing.

    This is great for game developers, but it has the potential to excite, then annoy(because they can’t really use it) application developers.

  3. This blog post is spot on. I see many forums filling up with people wanting to integrate flash/flex components hitting a wall and having to go trough all sorts of hoops to get nowhere. This does look like a step back. Just look at this example from 2007 This is something you can’t do anymore on the Molehill API.

Comments are closed.