AVM2: RemoveObject runs at the start of a frame & frame phase tracking
#7048
Conversation
…nd can respond to
…ame actions are done.
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.
…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
…rom the main one are merged in
|
|
||
| if is_playing { | ||
| // Frame destruction happens in-line with frame number advance. | ||
| // If we expect to loop, we do not run `RemoveObject` tags. |
There was a problem hiding this comment.
This is talking about looping back to the first frame, not 'looping' on the current frame, right?
|
Following from Discord discussion, I'm a little skeptical that FP would do multiple passes over the SWF tag stream per frame. I'd imagine it would do one pass over the tag stream, executing all of the tags, but deferring event dispatch until it knows exactly what the final state of the frame is. Here's an example SWF that does a PlaceObject of a clip, followed by RemoveObject of that clip, on a single frame: I admittedly don't have the full picture here, but I feel like deferring the event execution in this way would make the code simpler, allow us to possibly get all of the tag handling back into a single fn, and clean up a lot of the special cases. |
|
I'm going to prototype the "read tag stream in |
|
This was superseded by #7570. |
This PR does four things:
RemoveObjecthandling to theenter_framepart of frame processing, because it happens before theEnterFrameevent is emitted.enter_frame/construct_framecalls to one place. This also demonstrates how the frame phase tracking can be used to avoid sending events to objects too early or too late.avm2_simplebutton_constr_childeventsbecause it is reporting an extra accidentalEnterFrameevent. This doesn't happen in the PR I cut this off from, but I don't know why. Best guess is that something in [DRAFT] AVM2: Fixes forSimpleButton#7015 fixes it.