[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Hughes
Subject: Re[3]: [Gnash-dev] Re: gotoAndPlay bug in Gnash
Date: Wed, 09 May 2007 12:22:14 -0600

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.

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

- 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:


Gnash-dev mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]