Re[3]: [Gnash-dev] Re: gotoAndPlay bug in Gnash

[Eric Hughes]

Wednesday, May 9, 2007, 7:05:22 PM, Eric wrote:
EH> Rewinding to a previous execution state and going to a particular point of
EH> execution are distinct and very different operations.  gotoAndPlay is of
EH> the latter type.  It is not rewinding to some previous state, merely moving
EH> a current execution point.

At 11:54 AM 5/9/2007, Udo Giacomozzi wrote:
> Your concept is not exactly clear to me, however we need to jump to a
> previous point in the time line.

I don't know your mind, but I should point out that you may be betraying a 
fundamental conceptual problem.  GOTO can go both forward and backward in 
time.  This may lead to defects, if assumptions are made in the code that 
something has already happened that's not required to have happened.

From http://www.senocular.com/flash/tutorials/depths/?page=2:
> An example of this kind of refreshing is caused by using gotoAndPlay to go 
> to a frame which has already passed; going to frame 5 from frame 10 for 
> example. When this happens, Flash does this refresh allowing it to 
> correctly display the screen at this new frame as the progression of the 
> timeline has diverted from normal playback and therefore must be 
> completely re-conceived by Flash.

The key is that last phrase "completely re-conceived"

Contrast this to what is says on the wiki page about the timeline:
> 1. A "gotoAndPlay(_currentframe - X)" in a simple movie without any other 
> ActionScript code simply restores the exact DisplayList that was active in 
> that frame, including matrix and color transforms.

Now these two behaviors are just not the same.  "Restoring a display list" 
and "re-conceiving a frame" are different operations.

It seems like the implementation specification as _de facto_ exists in 
Gnash is wrong.  Well, not wrong in any absolute sense, but wrong in the 
sense that "it doesn't match Adobe Flash".





> EH> Wait a minute.  Is anything really restored, by which I mean, reverted 
> to a
> EH> previous state?
>
> No ActionScript variables, if that's what you mean. However these
> effects are possible:
>
> - instances being constructed / appearing (in case they didn't exist
>   at the time of the gotoAndXXXX call)
>
> - instances being destroyed / disappearing (the opposite)
>
> - instance matrix being modified (assuming the instance already
>   existed)
>
> - instance color xform being modified (dito)
>
> Don't know about sounds, but I don't see any other effect.
> ActionScript is not directly involved except for constructed/destroyed
> instances or script code in the target frame.
>
>
> EH> Or are these instances simply added to the frame as if
> EH> GOTO were absent and the frame were duplicated as the next frame?
>
> Nothing is duplicated.
>
>
> EH> There seems to be an inconsistent story here about what's happening.  When
> EH> a GOTO executes, does it restore something (which I would consider
> EH> "something special") or doesn't it ("nothing special")?  I can see that it
> EH> might have to display something; fine.  Does this display act like a
> EH> restoration or like an initial display?
>
> Can't follow you, but I think my list above answers your question.
>
>
> EH> I can understand a desire to avoid recomputation, but _that's_ a 
> caching or
> EH> memo issue rather than a behavior-definition one.
>
> Avoiding recomputation is only a side effect. There are too many
> special situations we need to keep track. Just look at the updated
> wiki page:
> http://www.gnashdev.org/wiki/index.php/TimelineControl
>
> Udo
>
>
>
> _______________________________________________
> Gnash-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnash-dev