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

[Udo Giacomozzi]

Strk and me had a discussion about display lists and jumping between
frames.

We discovered that this problem does not just knock out invalidated
bounds but is actually a very serious bug in Gnash.

-- The problem:

When looping back (for example, gotoAndPlay(_currentframe-1); )
Gnash resets the sprite's display list and reconstructs it by
executing all frame tags again until the target frame.

This causes *everything* in the target frame to become new instances.
Now, when looping back to a frame that still contains the same sprite
instance this instance will be re-created, causing all ActionScript
variables and other stateful information to be lost and actions in the
first frame of that instance to be executed!

With other words: jumping between frames leads to lots of problems.

As a side effect set_invalidated() is called without need, but this is
now a secondary problem.

Jumping to frame 0 is a special case because it has a dedicated
_frame0_chars display list. However, this can't be a solution.


-- The solution we're discussing:

Generally we would need to get rid of the recreation mechanism.
goto_frame() should be able to build the correct display list without
browsing through all frames.

This way goto_frame() can do a before/after comparison and
destroy/create sprite instances as needed, including correct
ActionScript execution and invalidated bounds calculation.

One way is to keep a DisplayList for *each* frame of a sprite. This
most probably would eat lots of RAM.
   
Add a TimelineInstanceInfo member to sprite instances which keeps
track of the first and the last frame in which the instance is
supposed to be alive. So goto_frame() just needs to look at all known
sprite instances and pick those that match the target frame.

A similar approach is implemented in SWFDEC.

The "last frame" information can be temporarily unavailable when the
movie has not yet been fully loaded, which should not be a problem
since goto_frame has to wait for that frame anyway when jumping
forward.

However, this information must be build at parse time since it needs
to be immune to ActionScript code. Basically we're reconstructing the
timeline just like it is being shown in the IDE.

The permanent sprite instances would be just copies, because
ActionScript variables and changes to the instance properties via
ActionScript need to be discarded when a instance is placed again on
the real DisplayList.



I have only superficial knowledge of this part of Gnash, and don't
think I could do this change myself. However, this must be analyzed
very carefully. So, discussion is open :)

Don't know if this is a important release criteria. However, I think
this is a serious bug.

Udo