gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Re: [Gnash] Playing multiple movies at the same time


From: Sergio Garcia Murillo
Subject: Re: [Gnash-dev] Re: [Gnash] Playing multiple movies at the same time
Date: Mon, 20 Aug 2007 19:17:50 +0200

----- Original Message ----- 
From: "strk" <address@hidden>
To: "Sergio Garcia" <address@hidden>
Cc: <address@hidden>
Sent: Monday, August 20, 2007 5:20 PM
Subject: Re: [Gnash-dev] Re: [Gnash] Playing multiple movies at the same
time


> On Mon, Aug 20, 2007 at 05:07:38PM +0200, Sergio Garcia wrote:
>
> > What about the following patch to start with? I have move most of the
statics to the vm and
> > create the getter/setters on it, then just proxy the statics function to
the vm singleton ones.
>
> The idea of the singleton (which should be inherited by the non-singleton
design)
> is that you'd set all stuff at construction/initialization time.

I don't like the idea of the singleton at all, but I don't want to start a
flame war, and it's
easy (and stupid) to criticise something when you have just take a look at a
few files :)
The only use (rigth now) for the VM is storing the movie and the garbage
collector.
For that use you don't need a singleton and it doesn't matter if you create
an object at
the begginng or create one when you call init, as all it does is just store
the pointers.
I think we should redisgn the whole idea of the vm (more on this later).

> I wouldn't feel comfortable with things like base url or renderer being
modifyable
> once the VM is created. Might be this would mean many parameters in the
constructor,
> or maybe another class which is initialized by passing a VM and some other
context
> container (for renderer,base url and the like).
>
> I guess every *run* (movie) would need:
> - A VM (which would have a GC)
> - A base url
> - A render handler
> - A sound handler
>
> You might encode these 4 members into a context class (Application?).

Yes, I was thinking in doing something like that, use the VM just as a
factory.
We'll have a singleton of it and it will just load the default configuration
parameters
for all movies and even log files, debugs, etc.. and create instances of the
"application context".

> Let me know if this makes sense for you, I haven't really tried the patch
> at all, just trying to point out possible dangerous uses.

It's just the first move, the hardest work is going to be appending
references to the
app_context (pr the relevant object) in every place that is needed.

BR
Sergio





reply via email to

[Prev in Thread] Current Thread [Next in Thread]