Intro
Flash is a lot of things. The best way to think of it is that it's just a web browser with a very rich API surface. Many of these features already exist in HTML5 and JavaScript in one form or another. The goal of Shumway is to map these features onto HTML5 whenever possible and polyfill what is not yet available in the Web platform.
Let's dissect the Flash player:
It's made up of a lot of different pieces, many of which are redundant:
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.
-
AVM2: Is used to execute ActionScript 3. Adobe open sourced the AVM2 engine under the name Tamarin a few years ago but we can't use it because it's written in C/C++. We do however use Tamarin for testing. AVM2 can be tested independently of the Flash player and is a self contained sub-project within Shumway. To gain 100% compatibility with Tamarin, we need to pass the Tamarin Acceptance Suite. This is a challenging task because some of the features available in ActionScript3 (AS) don't have direct equivalents in JavaScript (JS). For instance, AS supports E4X an XML sub-language which we used to support in our JavaScript engine (SpiderMonkey) but have since removed it. To implement this feature of AS3 we have to re-implement E4X but on top of JS rather than at the JS engine level. Other features that are hard to deal with are: proxies, vectors, weak references, security domains, regular expressions. Full compatibility with the test suite may not be possible, but we may still be able to support most content.
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.
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.