Re: [Gnash-commit] gnash ChangeLog server/character.cpp server/cha...

[zou lunkai]

> Things to test (important):
>
>  1) what happens if the target depth after the shift is occupied.

AFAIK, this could never happen(at least in normal cases).

>    For example:
>        - mc1 placed with onUnload event at depth 2, then removed (shifted 
> down)
>        - mc2 placed with onUnload event at depth 2, then removed (shifted 
> down occupied)
>        - both onUnload handlers will need to reference 'this' and verify they 
> point
>          to the correct instance (mc1 or mc2) Better if they both have the 
> same name!
>

We can not place both mc1 and mc2 at depth 2 within the same timeline.
So I don't worry about this case:)  If  mc1 and mc2 are of different
timelines, Gnash shouldn't have difficulty with them, right?

>  2) How is it possible for an unloaded character to be out of the unloaded 
> depth zone

It is *possible* for characters without onUnload defined. Sprites
without onUnload defined are not shifted to the unloaded-depth-zone.
So if you check these sprites before destroying them, it's not
surprise that you found them unloaded but still in the
static-depth-zone.

This is already tested in movieclip_destruction_test1 and Gnash
passed. I might add some more later.

>  4) Add a test for characters out of the "removed" zone not being marked as 
> 'unloaded' in the
>    DisplayList::testInvariant() and run as many SWF till gnash crashes :)

Well, this is too specific to Gnash implementation. I need to review
the code to understand what is going to be tested. Characters out of
the removed-zone and not marked as 'unloaded' are very normal in the
concept model:)

--zou

On 9/1/07, Sandro Santilli <address@hidden> wrote:
> On Sat, Sep 01, 2007 at 01:20:47AM +0000, Sandro Santilli wrote:
>
> > Log message:
> >               * server/dlist.{cpp,h}: when unloaded character's unload() 
> > method
> >                 returns true (character or any of its childs has onUnload 
> > methods to
> >                 be run) don't really remove it from the list, but just 
> > shift it
> >                 down to the "removed" zone. Advance and display only 
> > non-removed
> >                 characters (depth-zone based for now, possibly too weak).
> >                 Add lots of paranoid invariant testing (not enough, missing 
> > the
> >                 one for no unloaded characters out of "removed" depth zone).
> >               * server/character.{cpp,h}: more info about 
> > removedDepthOffset,
> >                 assertion preveing double unload of a character (this can be
> >                 probably easily broken by a focused testcase using 
> > removeMovieClip
> >                 on a removed but still-reachable character).
> >               * server/movie_root.{cpp,h}: added cleanupDisplayList() 
> > method, and
> >                 call it at the end of actions execution to properly cleanup 
> > removed
> >                 but still-reachable characters.
> >               * server/sprite_instance.{cpp,h}: implement a 
> > cleanupDisplayList, to
> >                 be called by movie_root, make sure to not include unloaded
> >                 characters when visiting the DisplayList for bounds 
> > extractions and
> >                 similar.
>
> This is a pretty big change. We don't always really remove characters from 
> the DisplayList,
> but we keep them alive if they (or their children) have any onUnload event 
> handler to be
> executed. In that case we only shift them down to a different depth (verified 
> to be the
> expected behaviour).
>
> Things to test (important):
>
>  1) what happens if the target depth after the shift is occupied.
>    For example:
>        - mc1 placed with onUnload event at depth 2, then removed (shifted 
> down)
>        - mc2 placed with onUnload event at depth 2, then removed (shifted 
> down occupied)
>        - both onUnload handlers will need to reference 'this' and verify they 
> point
>          to the correct instance (mc1 or mc2) Better if they both have the 
> same name!
>
>  2) How is it possible for an unloaded character to be out of the unloaded 
> depth zone
>    I've seen this with bombgame.swf, for which line 2360 of 
> sprite_instance.cpp currently
>    cleans out unloaded characters from the newlyAdded DisplayList.
>    Still, I don't know how was it possible for a character at depth -16381 
> (3) to be
>    tagged as "unloaded" (it should have been moved down to -16388 when removed
>    (-32769-(-16381))
>
>  3) Implement pixel-checking for some of the available depth-based tests 
> (IIRC displaylist_depths_test.c
>    had some weird visual behaviour, which may now be explainable)
>
>  4) Add a test for characters out of the "removed" zone not being marked as 
> 'unloaded' in the
>    DisplayList::testInvariant() and run as many SWF till gnash crashes :)
>
> --strk;
>
>
>
> _______________________________________________
> Gnash-commit mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnash-commit
>