[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash (was: Serious performance p
From: |
Udo Giacomozzi |
Subject: |
Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash (was: Serious performance problem) |
Date: |
Tue, 8 May 2007 09:38:45 +0200 |
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
Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash (was: Serious performance problem), zou lunkai, 2007/05/08
Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash (was: Serious performance problem),
Udo Giacomozzi <=
- Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash (was: Serious performance problem), Sandro Santilli, 2007/05/08
- Re[2]: [Gnash-dev] Re: gotoAndPlay bug in Gnash (was: Serious performance problem), Udo Giacomozzi, 2007/05/08
- Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash (was: Serious performance problem), Sandro Santilli, 2007/05/08
- Re[2]: [Gnash-dev] Re: gotoAndPlay bug in Gnash (was: Serious performance problem), Udo Giacomozzi, 2007/05/08
- Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash (was: Serious performance problem), Sandro Santilli, 2007/05/08
- Re[2]: [Gnash-dev] Re: gotoAndPlay bug in Gnash (was: Serious performance problem), Udo Giacomozzi, 2007/05/08
- Re[3]: [Gnash-dev] Re: gotoAndPlay bug in Gnash (was: Serious performance problem), Udo Giacomozzi, 2007/05/08
Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash (was: Serious performance problem), zou lunkai, 2007/05/09
Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash (was: Serious performance problem), Sandro Santilli, 2007/05/09
Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash (was: Serious performance problem), zou lunkai, 2007/05/10