> > > > So the next question is should I look into implementing some kind of > > pipe, or possibly redoing the plugin? I guess this would be a lot of > > work either way (maybe too much for a lowly intern :o). Seems like it > > might be interesting work anyway. Any help or opinions will be most welcome. > > If it doesn't scare you too much, working on the reentrant core lib > is the most useful thing to do. >
Right, here the biggest problem is the VM, which is currently a singleton and accessed from all sorts of places where it shouldn't be. The renderer is also currently a problem, but I have a plan and most of the implementation to add that to the RunInfo (I think doing this will also help BitmapData.draw), and pass it to all display() functions from movie_root. Other problematic statics are: 1. AS class constructor functions (called from the *_class_init functions). I don't know why these are static, because they are added as members of the global object (or members of members) and are so protected from being cleaned up by the GC. The only other reason would be to handle cases where the *_class_init function is called more than once. I don't think this should happen, but I haven't checcked very extensively. 2. Object prototypes (the get*Interface() functions). My best idea at the moment is to attach them also to the respective Global object. Because we have an AVM1Global and an AVM2Global, it would be possible to make these a subclass of a base class Global, with a function looking like: as_object* Global::getPrototype(string_table::key name, as_object* interface) Because all built-in prototypes have a unique name (it may be more future-safe to include the namespace as well), the respective Global object could store a map of name - prototype and either return an existing one or create a new one. Fixing part 1. is easy if I'm correct. Implementing part 2 means changing a lot of functions. It also means that every as_object ctor needs to take an extra argument to get the VM from (or the movie_root, or the Global object, depending on what we want to make the central class for getting these resources). This is because ctors call the get*Interface() functions, which in turn need to know what the Global object is. There are many other possibilities for 2, but because it in any case requires such massive changes it needs discussion before starting on anything. Using a polymorphic Global object as the central reference point for AS resources has the advantage that it doesn't increase use of the VM; it might be useful in future to stop accessing the Machine through the VM. After all that's done, there are still some uses of the VM or movie_root during parsing. I think that would be more or less the last difficulty, and I haven't got any very advanced ideas about how to fix it. bwy -- The current release of Gnash is 0.8.5 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 Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
