Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash (was: Serious performance problem)

[Sandro Santilli]

On Tue, May 08, 2007 at 09:56:57AM +0200, Udo Giacomozzi wrote:
> Hello Sandro,
> 
> Tuesday, May 8, 2007, 8:38:57 AM, you wrote:
> SS> If we store a TimelineInfo object to "static" objects we might
> SS> solve this problem. The TimelineInfo might be a pointer to the
> SS> PlaceObject2 tag (now in its own header extracted with this 
> SS> in mind) and the frame number in which it was executed.
> 
> To have the information about depth, position and such?

In particular to have information about the actual TAG creating it.
When we fetch tags of a particular frame (get_playlist, or something like that)
we get a list of pointers. We can do pointer matching to find out wheter
an instance has been created by a specific PlaceObject2 tag.

> SS> Things to check before proceeding (by adding more testcases)
> SS> are:
> 
> SS> - What happens when instance in frame 2 changes it's matrix
> SS>   or depth due to a PlaceObject2 tag in frame 3 when looping back
> SS>   from frame 6 to frame 4 ?
> 
> What *should* happen is that the new matrix/depth set in frame 3 is
> restored.

Is it "restored" in the sense that any further PlaceObject2 modification of 
matrix
in frame 5 is discarded ? Can we have a testcase for this ?

> Regarding to our solution: good question. I guess we need to
> have for each sprite instance:
> - a list of placeobject / removeobject tags (or references to them)
>   including frame number
> - number of last known frame
> Does this sound?

Sounds fair: a list of displaylist tags that in any way modified this instance,
accompanied by the frame number. These are pointers, so no big mem problems.
Dynamic instances (ActionScript-created) would have an empty (or unexistent) 
list,
this difference can be used to implement isDyamic().

An example list would be:

        PlaceObject2 in frame 2
        PlaceObject2 in frame 3 (move)
        RemoveObject in frame 4

Is the last item in a *complete* list always a RemoveObject ? I'm afraid we 
can't
say so as we can have instances that are *never* explicitly removed.

> SS> What if we loop back to 2 or to 3 ?
> 
> Of course, PlaceObject2 settings of the respective frame need to be
> restored.

Is onClipLoad invoked again ? Are AS values reset ?
Can we have a testcase for this ?

> SS> - Are dynamic instances moved to the "static range depth" by ActionScript 
> also
> SS>   removed by loopback ? (see misc-ming.all/displaylist_depths_test.c)
> 
> Removed? You mean when looping back to a frame *prior* to the
> PlaceObject2 tag? Yes, they're also removed.

Have a testcase for this ? 

> SS> - Are static instances moved to the "dynamic range depth" still removed by
> SS>   loop-back ? (again, see displaylist_depths_test.c)
> 
> As said above, they're *not* removed on loop back and PlaceObject2
> adds a new copy to the stage. So after the loop you have two
> instances.

Uh ? So if we use swapDepth() on an instance we then have to threat it
differently then if we didn't when it comes to DisplayList reconstruction
on loop-back ?
Testcase ?

> SS> - Are load/unload events of instances placed and removed before
> SS> the target frame of 
> SS>   a loop-back invoked again ?
> 
> When looping back to a frame *prior* to the PlaceObject2 the movieclip
> actions get executed later, when entering that frame. Don't know what
> you mean with "removed"..

MC1: placed in frame 2, removed in frame 3
>From frame 6 gotoFrame(5) <-- does this call any MC1 clip event ?

--strk;