Let's dissect the Flash player:
It's made up of a lot of different pieces, many of which are redundant:
AVM (ActionScript Virtual Machine)
AVM is the code execution engine at the core of the Flash player. There are in fact two such engines in the Flash player that support a total of 3 languages, ActionScript 1, 2 and 3.
AVM1: Is used to execute old Flash content: ActionScript 1 and 2. We have some support for this in Shumway but most of our effort has gone into AVM2.
Display List & 2D / 3D APIs
Flash has a concept similar to the HTML DOM, called the Display List. The Display List keeps track of the position, scale and visibility of elements during an animation. The Display List can be manipulated in two ways: through a stream of commands stored in 'SWF' files and programatically using ActionScript. Designers normally use a tool called Flash Professional that lets you draw and animate things, and occasionally write a bit of scripting code to control the animation. Developers use something called the Flash Builder and control the Display List directly through code. This is all very similar to how the web works, except that both code, graphic assets and animations are packaged into a compact file format called 'SWF' rather than plain text as is the case in HTML.
Implementing the Display List in Shumway is challenging primarily because nobody knows how it works exactly, the code is closed source, undocumented and needs to be reverse engineered.
At some point Adobe wanted to give developers the ability to draw things procedurally, the same way the Canvas element works in HTML5. This API is similar to the Canvas API but it's different enough that there isn't a straight forward translation. There is a sub-project in Shumway called Kanvas that attempts to emulate the Flash Player's 2D API surface.
Getting good performance in Shumway for Display Lists and 2D APIs will involve a combination of DOM Layers, Canvas and WebGL. At the moment, we're just using Canvas but that will need to change in the future.
When 3D hardware accelerated devices became popular Adobe decided to provide an API to surface the graphics hardware in a platform independent way, meaning it needed to interface with both OpenGL and DirectX. They came up with Stage 3D (aka Molehill) and a new shader language called AGAL (Adobe Graphics Assembly Language) which compiles to GLSL and DirectX shaders. If we ever want to support Stage 3D Flash content we need to do what they do when compiling to Stage3D to OpenGL, but to WebGL instead.
This is where it gets messy. Flash's primary use is that of a video player. Adobe packed a bunch of codecs in the player that we're not likely to be able to support, unless the underlying operating system provides them.
To expose all these features in the Flash platform, Adobe ships a file called the 'playerGlobals.swc' with each version of the Flash Player. The file describes the entire Flash Player API surface and is partially implemented in ActionScript, a majority of the functionality however is stubbed out as being 'native' which means it's implemented in the Flash Player itself in C/C++. The ActionScript implemented portions of the API are nice because we don't have to worry about them (as long as our AVM2 engine works well), the rest we need to implement ourselves and this is the bulk of the work in the Shumway project. This range from very simple APIs to deal with context menus to complicated networking, DRM, you name it. Adobe had years to keep piling functionality to the player.
At some point, someone at Adobe figured they could allow developers to write Flash applications that behave like Desktop applications. They took WebKit, removed the chrome, poked a bunch of holes to allow access to the file system and other lower level APIs, embedded one instance of the Flash Player and branded it as Adobe AIR (Adobe Integrated Runtime). Since the AIR APIs are not available to developers targeting the Flash Player in normal browsers, Adobe versioned the player global APIs to indicate in which platform they are available. We don't have any plans to support the AIR APIs, but we could theoretically, the Web APIs might be a target candidate.
Apache (Adobe) Flex
With so many APIs around, Adobe figured they would add some more, but this time entire application frameworks, UI toolkits, etc. Luckily, this is all implemented in ActionScript 3 on top of the Flash Player and AIR APIs.