I'll answer these in reverse order: > Flash 10 seems to contain AS3 (ActionScript 3) which is implemented by > AVM2. The implementation includes:
> * a bytecode interpreter > * memory management, initialization, etc. > * a builtin class library > * graphical back-ends for painting, audio, video, input, etc > * (anything else important?) > > Are the other pieces all in good shape? > > So can our gnash initialization start running an AS3 "ABC file"? Is > that what Youtube is offering from its web site, e.g. from: > Here a brief outline of flash versioning, as it's not very clear to many people: The version of a SWF file (currently 1 to 10) is stored in the header. It has some effect on the way files are executed, particularly for versions 1-8, but is completely irrelevant for which virtual machine is used. It's possible for a SWF to be version 10 and to use only ActionScript 1, or (probably) to be version 1 and run ActionScript 3 (AS3). More important is the VM version. Another flag in the header determines whether the player will use AVM1 or AVM2. AVM2 is the machine for AS3, which consists of ActionScript Byte Code (ABC). An ABC file is a SWF file that has the ABC header flag set to true. ActionScript (all versions) is stored as bytecode only in specific tags. AS2 is stored mainly in DoAction and DoInitAction tags. AS3 is stored in DoABC tags. Both types of tag can be present in any SWF; the player will simply ignore one of the types according to the ABC header flag. There are a few more tags specific to AS3, especially the SymbolClass tag. Most other tags are common to AVM1 and AVM2. They handle things like defining MovieClips, fonts, or TextFields, morphing and translation of DisplayObjects, Bitmaps and so on. Different versions of the tags have been introduced steadily since the beginning of Flash, but as a rule any of these tags can be used in any version. Gnash has support for ABC execution, and has a basic testsuite to prove it. Gnash also parses and executes the SymbolClass tag. This is the one used in initialization, and Gnash currently can't implement it properly because it relies on making an already-constructed object into a Sprite or MovieClip. > Benjamin, you seem to be reworking the builtin class library (because > it isn't sufficiently flexible to be able to do many things that seem > common in AS3?); is that true? More or less. The "built-in class" library describes the whole API of the player, both the functions native to the player and the classes defined in ActionScript and executed on initialization (Gnash doesn't do it like this, by the way, but rather implements these classes in C++, which may or may not be a good idea). The built-in AS3 classes are mostly stubbed, some more accurately than others, and some functions already work. Mainly what I'm doing is working on the native part of this, which includes the DisplayObject classes. Those are objects that can be put on the stage and displayed, including videos, bitmaps, shapes, morphs, and text. I'm not working on AS3 functions, but rather the way these objects are implemented behind the scenes so that it becomes possible to turn simple objects into DisplayObjects. -- Use Gnash, the GNU Flash Player! http://www.gnu.org/software/gnash/ Benjamin Wolsey, Software Developer - http://benjaminwolsey.de
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
