> 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 <[EMAIL PROTECTED]> 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
> Gnash-commit@gnu.org
> http://lists.gnu.org/mailman/listinfo/gnash-commit
>
_______________________________________________
Gnash-commit mailing list
Gnash-commit@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-commit
