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

[Udo Giacomozzi]

Hello Eric,

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

Currently we try to solve a problem that we currently only have when
jumping backwards. However, the solution works for jumping forward
too.

Consider three instances:

A lives from frames 3 to 5
B from 8 to 10
C from 13 to 15

when jumping from frame 4 to frame 14 (or the other way round), there
won't be a instance "B" created at any time.

Also note we're just translating the static information contained in
the SWF file (PlaceObject, RemoveObject) to a different structure that
is much more like it has been designed by the SWF author. And it
allows us to reconstruct any frame number instantly.


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

Yes, that's what we are doing. TimelineInfo is just a much simpler way
as opposed to scan through all PlaceObject/RemoveObject events.

Simpler here means: The implementation of "goto_frame" is simpler. And
that's important since it must handle a number of special cases.


EH> 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.

Ok, maybe I did not explain this correctly. With "that was active in
that frame" I mean without considering effects of ActionScript
commands other than GOTO. I did so to simplify the discussion. When
you need to consider ActionScript you go to the same low level Sandro
and I am currently digging (which is pretty deep), but you're welcome
:)

It's much easier if you do some top-down way to understand the
problem/solution/concept. First, consider a pure static movie - only
ActionScript code is gotoAndPlay(). In that case my older statement is
still correct.

When we come to instances that have been touched by ActionScript code,
there are three different cases, which are explained on the wiki page:
http://www.gnashdev.org/wiki/index.php/TimelineControl#What_.22should.22_happen_when_jumping_backwards

Note you come to a level where we still need some clarifications.

What we know for sure is:

- instances *created* dynamically never care about gotoAndXXXX

- instances created statically react in different ways to gotoAndXXXX,
  depending on ActionScript code that may have modified the instance


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

Correct.


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

It points in the correct direction, but is difficult to maintain (in
respect to all these special cases) and is buggy.

Just look at how long that wiki page is so you have an idea how
complicate gotoAndXXXX is...

Udo