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 _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
