gnash-commit
[Top][All Lists]
Advanced

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

Re: [Gnash-commit] gnash ChangeLog testsuite/misc-ming.all/Makefil...


From: strk
Subject: Re: [Gnash-commit] gnash ChangeLog testsuite/misc-ming.all/Makefil...
Date: Sun, 25 Nov 2007 11:14:07 +0100

On Sun, Nov 25, 2007 at 12:08:11PM +0800, zou lunkai wrote:
> > On Fri, Nov 23, 2007 at 03:59:19PM +0800, zou lunkai wrote:
> > > > Doesn't one of the redesign attempts account for this ?
> > > > One was: "keep info about which static character belongs to each frame"
> > > > mc3 was placed in frame 4 and still alive, we're jumping to frame 5
> > > > so why should we build it again ? I guess its just the 'ratio' thing
> > > > preventing that, right ?
> > > >
> > >
> > > The problem is not ratio. It is mc1 and mc3 occupy the same depth.
> > > When jumping back, mc1 need to be constructed again, which need a
> > > depth already occupied by mc3.  We don't know where to place mc1 at
> > > construction time when jumping back.  (Of course, to solve this single
> > > case is not difficult, but it hurts current design)
> >
> > Do we really need to construct it or simply calling initialize handler
> > does it ? The handler itself shouldn't be able to find mc1 anyway, right ?
> >
> 
> The actions code  in the event handlers(INITIALIZE, CONSTRUCT, UNLOAD)
> are able to find mc1. They are not special(tested with 'this',
> 'getDepth').  There's updates on wiki TimelineControl, but haven't
> been finished yet.

I've read the 5th redesign attempt, looks promising.
I guess next step would be going on each of the scenarious listed on
the wiki and verify it wouldn't break it.

--strk;




reply via email to

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