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

[Udo Giacomozzi]

Hello zou,

Tuesday, May 8, 2007, 5:43:39 AM, you wrote:
zl> We need to improve the recreation mechanism when jump back, in other
zl> words, only re-create those need to be re-created. eg. characters
zl> removed at current frame but appears at target frame. We need to scan
zl> all frame tags from frame0 to target frame to find out which placement
zl> tags are responsible for handling(ADD, MOVE) this character.

Yes, my first idea was to pass a temporary DisplayList to
execute_frame_tags() and avoid changing anything the real sprite
instance. However, that function and everything it calls seems to be
closely tied to sprite_instance so this would mean a huge rewrite.

Browsing through frames also has the disadvantage of being inefficient
in terms of performance. I wonder if MM player does it this way.


>>One way is to keep a DisplayList for *each* frame of a sprite. This
>>most probably would eat lots of RAM.

zl> This is a simple way, but costs too much memory.

Agree, that's why we keep lifetime info ("TimelineInfo") for each
instance and have only one copy in memory. I think that is acceptable
because a typical movie does not have that many *static* characters in
it. I assume a character instance does /not/ need a lot of memory.


zl> And the "DisplayList
zl> " might be changed at any time when executing action scripts.

Right, but those will be restored when jumping back. Example:

- static sprite instance in frame 3
- frame 5 swaps it's depth and removes it from the stage
- frame 7 loops back to frame 4

The sprite re-appears in frame 4.



A special case seems to be *moving* a static sprite. When, in the
above example, changing
  _x += 50;
  _y += 50;
instead of removing it (and *not* changing depths), the instance keeps
on moving and it's original position is /not/ restored when looping
back. AFAIK this is because the sprite instance gets a special state
when such properties are changed (can't remember the right term).


Furthermore, when swapping depths before changing the coordinates I
get exactly one *new* instance when looping back. So two instances move
along. I guess this is because I can't swapDepths() to an already
occupied depth.


zl> That
zl> means you need to maintain lots of DisplayLists for a single sprite.

They're not really DisplayLists, it would be *one* special kind of
list where multiple sprite instances can have the same depth.


zl> In sprite_instance::goto_frame()
zl> resetDisplayList() clears all static characters placed from frame1 to
zl> current frame when jump back. Instead of doing that, I think we should
zl> just clear static characters placed from target frame to current
zl> frame. This might solve some problems above.

No, this would still re-create the sprite placed in frame 3 when we
loop back to frame 4. 

Udo