From Gnash Project Wiki

Jump to: navigation, search



We have a failure with gnash. The interesting scenarios to confront are:

  • Jumping backward to the midle of a character's lifetime after moving it to a static depth (display_list_depths_test3.swf)
  • Jumping backward to the start of two character's lifetime after depth swap (loop_test2.swf)

In the first case the character moved to a different depth is removed. In the second case the characters, both moved to a different depth are retained.

They tests are not exactly the same, a better test for confronting would be "Jumping backward to the start of a character's lifetime after moving it to a static depth"

In any case, the 2nd restoreDisplayList implementation is bogus as it removes too many characters (loop_test2.swf fails)

Failure 2

"Jumping backward to the start of a character's lifetime after being swapped to the depth of a subsequently placed character"

In this case the "removal" step seems to get rid of the *depth*, not the *instance* placed at that depth in that frame. The *depth* in which a character was placed in frame3 is cleared when jumping back to frame2. Unfortunately, at that depth we now find another instance, the one actually placed in frame2. And the one placed in frame3 keeps alive !!

This case shows that "Remove any character placed at a later frame" is wrong behaviour

Redesign attempt 3 ?

We should do more research about the 'ratio' thing, then implement a prototype for this. I'll work on the Timeline class today --Strk 04:49, 21 May 2007 (EDT);


Why we need attempt5

A: (1) attempt3 and attemp4 have made the semantics of PlaceObject, RemoveObject being too complex, hard to understand, hard to remember and hard to fix. (2)both attempt3 and attemp4 are timeline depths based, which implys that if a character in the target depth won't be unloaded, then that depth cann't be reused by any other character during jumping back. It's already broken by loop_test10.c

Would attempt5 simplify any thing

A: yes. (1) PlaceObject would always construct a new character if the specified depth is empty; (2)RemoveObject would always remove a character is the specified depth is occupied. (3)the trick only appears at the last step while comparing the old and new displaylist, which is easier to control and understand. (4)attempt5 would fit the actions order model better, where characters should be unloaded at the last step instead of first step(current implementation) when jumping back.(6)the sprite_instance::is_jumping_back flag is no more needed for all DLIST tags now:) DLIST tags would work the same in jumping back and jumping forward mode. (6)The Timeline class is also unneccessary, we don't need to analyze that(but could be used for some optimization work).

comments on attempt5 2.2.2

"if equal and the old character accepts static transformation, replace the transformation matrix of the old character with the matrix of the new character, and destroy the new character."

 The above rule is complex but not a new requirement in attempt5, just keep the logic in current   
 design should be enough.

comments on attempt5 4

"Copy all unloaded and destroyed characters from the new display list to the old display list, and clear the new temporary display list."

 At this step, we may have two unloaded characters share the same removed zone depth. Conceptually, gotoFrame might result 
 executing DLIST tags spreading in different frames at a single advance, so it is reasonable that there are more than one 
 unloaded characters share the same the depth.
 "clear the new temporary display list" is important at this step, we need a clean temporary list for next gotoFrame.
 After this step, characters are either transfered to the old display list or destroyed.

comments on attempt5 6.1

"Reset all references to unloaded/destroyed characters, wipe out unloaded/destroyed characters from their display list."

 I assume references are collected first and then pointers in display list, probably not the 
 fact in current implementation.  Anyhow, 6.1 is out of the TimelineControl topic.