From Gnash Project Wiki
Player interface initialization
Initialization of player interface consiste in making available all the classes and methods of the player API. What's available and what not depends on the SWF version the VM is initialized with, which is tipically the SWF version of the first loaded movie.
According to http://osflash.org/flashcoders/undocumented/asnative some of the player interfaces are native and some others aren't. Native interfaces can always be accessed using the global ASnative method, addressing all of them by a double numerical index.
Many websites contain AS-implementation of non-native player interfaces, suggesting that non-native interfaces are simply prebuilt-scripts which are run by the VM at initialization time.
By following the suggestion (using AS to define non-native builtins) we'd have the advantage of readly-available initialization scripts, well known and tested, at the only cost of setting up the infrustructure.
Swfdec uses a Ming-compiled swfdec_initialize.as script to serve as the initialization bytecode for all non-native interfaces. The script uses ASnative to reference native functions when needed.
Initialization of Gnash VM is pretty slow. There's still no analisys of the reason at time of writing, but here are some guesses:
- All interfaces are registered in the same way as they would for user-defined ones, which means scanning symbol tables rather then statically initialize them.
- Flags set on builtin interfaces require a double symbol table scan (see as_object::init_member/init_propery).
- Native functions registration performs a native table scan rather then a static definition.
- ... more guesses or better proper analisys welcome ...