Am Donnerstag, den 02.09.2010, 09:12 +0200 schrieb strk: > On Wed, Sep 01, 2010 at 08:29:15PM -0600, Rob Savoye wrote: > > So I've spent a little time looking at AVM2 VMs that are also open > > source. It seems that what we want to do is pass off any swf bytecodes > > Gnash sees to another VM, and get back something like a display list. As > > others have looked into this in much more depth than I have, I can't > > barely wait to be corrected. :-) > > I belive the task of a VM is just to interpret bytecode and invoke > exterior stuff for any method call or variable get/set. > Should not have any concept of a "display list" at all.
This is correct: the VM simply interprets ECMAScript/ActionScript 3 bytecode. Tamarin itself implements only the covers the core ActionScript classes, which include things like Dates, Booleans, XML etc. It's important to distinguish this core language, which is documented openly, from the Flashplayer API, which adds a layer on top of ActionScript and has no open technical documentation. That includes most AS3 classes, such as BitmapData, NetStream etc, but also the entire DisplayObject hierarchy. Those classes are compatible with the VM, in that their methods and associated objects interact with AS3 bytecode, but their most important aspect - that they can be displayed - is down to native player functions and completely separate from the VM. This separation seems much stricter than in AVM1. The VM supports static inheritance and runtime type information using traits and a static prototype chain: this works with arbitrary types, so the VM doesn't have to know about them. AVM2 has a different display list from AVM1. It may be possible to implement them together, but it's almost certainly not worth starting that way. Gnash already has a DisplayObject hierarchy that fairly closely resembles the AVM2 hierarchy. One important question is whether to use these DisplayObjects in AVM2, or whether to write a new (but effectively very similar) set of DisplayObjects for AS3. It's important to note that DisplayObjects are closely linked to ActionScript: they interact with objects when certain events occur, and they can be controlled by ActionScript. Because this happens in a different way in the two VMs, it's not trivial for one class to interact with both AVM1 and AVM2 objects. Whatever VM is used, the interface between native objects (DisplayObjects, BitmapData - see the AVM1 Relay system) and the AS objects is important, and that's the bit that would make it tricky to switch between different VMs. bwy
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
