AVM2 Queued Tags & Looping Gotos fixes #7570
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Aug 7, 2022
kmeisthax
force-pushed
the
avm2-queuedevents
branch
from
50a1d6d to
a0b1eb0
Compare
adrian17
reviewed
Aug 12, 2022
kmeisthax
force-pushed
the
avm2-queuedevents
branch
2 times, most recently
from
4c07bee to
8a6f1d1
Compare
kmeisthax
force-pushed
the
avm2-queuedevents
branch
2 times, most recently
from
7605b72 to
787f5ba
Compare
Aaron1011
approved these changes
Aug 24, 2022
kmeisthax
force-pushed
the
avm2-queuedevents
branch
from
06cadac to
e9fd981
Compare
…clip back and forth to better demonstrate a bug I ran into with frame numbering
The test output for this test is sensitive to where we cut off each frame, because it doesn't stop all of it's handlers at the end of the test. Flash Player will just print lines forever so the end of the test is entirely arbitrary.
…, `frameConstructed`, and `exitFrame`
…ist what children are on the timeline
…e root movie clip too
…`, and/or `exitFrame`
…`, and `frameConstructed`
… broken by fixes I moved to another PR
…ame` into a single method, `catchup_display_object_to_frame`. The rationale for the catch-up logic is as follows: * We must always enter-frame and construct objects, even if those respective display events haven't happened yet. * Display objects created in event handlers still need to run catchup phases, otherwise they will tag-stream desync * Frame scripts are never triggered by catchup phases * `exit_frame` is not a catchup phase as it is *only* an event broadcast currently
…ve actions are queued until later. This prevents repeated place/remove actions at the same depth from resulting in repeated event dispatches.
They are no longer needed, frame advance happens at enterframe time.
…have fully completed.
…he new timeline position has been set.
… frame number advances.
We still retain the queue system as events are fired at removal time, and those events can trigger more gotos. If such a goto happens, AS3 code will hit a clip still in the old state rather than an inconsistent one. I don't have test coverage for this exact scenario just yet.
… in that order only.
…lip, even if we already executed that script beforehand.
This is in keeping with the whole idea of a "recursive frame": gotos run the entire frame lifecycle on the target clip, including broadcasts for `frameConstructed` and `exitFrame`.
… scripts on one another.
…enforces our queueing invariants
kmeisthax
force-pushed
the
avm2-queuedevents
branch
from
8a9e646 to
9011e7a
Compare
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a rewrite of much of #5876, minus the SimpleButton 'fixes' from #7015. It also includes the frame lifecycle changes in #7048.
@Herschel suggested I stop scanning the SWF three times, and instead just maintain an internal tag queue on each clip for running each event. Our exact structure is a
HashMapwith one queue per depth; with code maintaining the invariant that we only allow aPlaceObject,RemoveObject, or remove-then-add pair on each depth. Any other SWF tag structure on a given depth is normalized to one of these three patterns. This is vaguely reminiscent of theGotoPlaceObjectqueueing system, but we cannot use that type across frame phases as it is not'static.I'm far more confident in this design than my prior PR, which was prone to tag-stream desyncs. A large amount of the commits in that PR were purely just to correct for
gotohappening at inconvenient times between tag stream scans. The other half were to emulate the queue system without using a queue.