Re: [Gnash-dev] Implementing ExternalInterface

[Benjamin Wolsey]

> > 
> > 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