Re: [Gnash-dev] Timeline control and the gotoAndPlay bug

[strk]

On Thu, May 10, 2007 at 04:30:48PM +0200, strk wrote:

> http://www.gnashdev.org/wiki/index.php/TimelineControl
...
> For the wiki, an important task is organizing a complete-as-possible
> set of scenarious ("cases") writing them down in a consistent format
> under the section "3 Analysis of the proprietary player".

After a morning  discussion with Zou about the redesign model
(section 4 "DisplayList reconstruction design") we came out with
a second attempt ready for validation.

Since it seemed clean and effective I gave it a try to see how our
new self-contained testcases dealt with it, and the results seems
promising :)

With my patch we get 12 unexpected successes and NO unexpected
failure from our testsuite.  Basically, the patch adds a
sprite_instance::restoreDisplayList(size_t targetFrame) method that
currently only takes care of jump-backs (not jump-forward).

It's use is from sprite_instance::goto_frame() only, and relies on
the proper association of TimelineInfo records to timeline instances.
This is done using the new character::setTimelineInfo(int depth,
size_t frame) method, invoked at PLACE or REPLACE time by the
corresponding handlers in sprite_instance class.  The most painful
part has been ensuring to get the 'frame' parameter right, which
is basically obtained by ensuring everytime we call execute_frame_tag(x,
DLIST_TAG) m_current_frame == x (which exposes another possible
simplification/cleanup: dropping the first arg).

At this point the model really needs more break attempts to ensure
it is correct and also ensure these internal changes are not breaking
undocumented assumptions in Gnash codebase.

In particular, we have a lot of scenario/cases on the wiki which
are *not* accompannied by automated testcases, and we are surely
missing more scenarios, for example the effects of a
_parent.gotoAndXXX(current-x) triggering destruction of the instance
containing the code, which seems to fail an assertion with one of
movies in my collection.

The code is committed, but can be easily disabled if turns out
to expose really bad bugs.
To disable, comment out the #define NEW_TIMELINE_DESIGN 1 line
on top of sprite_instance.cpp. Note that gnash testsuite would
fail once disabled though..

All tests welcome.

-- strk;

 ()   ASCII Ribbon Campaign
 /\   Keep it simple!