Changes to the action queue caused actions queued during other
actions to run too late. These regressions weren't caught by the
tests because many of the goto tests ran for more frames than was
necessary, allowing the late actions to still run.
This is just testing that it exists and returns the same values as
getBounds for shapes without strokes.
TODO: When it is properly implemented for strokes, add stroked
shapes to testing.
Interestingly enough, very little actually has to be done inside the async process for XML. The async process basically just fetches data and fires an event handler when it's done. Everything else is handled via a system builtin, `XML.onData`.
This implementation just returns the size of the current loaded movie. The test is also deliberately written to be loose on timings so that it likely won't see a partially loaded movie. (I don't want it to be a test of load events, so I just wait a few frames, rather than the correct way of waiting for `onLoadComplete`.)
Until we support streaming file loads, we can't faithfully support these properties. Still, it's better to have them, just in case.
This is technically better, but it may make more sense to trigger `ClipEvent::Load` at the start of the next frame instead. Furthermore, I don't know if other forms of load events should trigger on the next frame (or end of the current one) like this.
Loads in Flash Player, like all web technologies, are asynchronous tasks of some kind (probably a separate thread). They appear to operate on some kind of a delay. If I `trace` each frame out, like in the previous version of `mcl_loadclip`, you get a series of events that look like this:
1. Parent frame 1
2. Parent frame 2
3. Event: onLoadStart
4. Event: onLoadProgress
5. Event: onLoadComplete
6. Parent frame 3
7. Event: onLoadInit
If I run that version of the test on Ruffle, everything happens after frame 1. This is an artifact of how we're testing asynchronous behavior in Ruffle. In order to guarantee test determinism, we have a dummy implementation of `fetch` that does a blocking load, and we poll all futures every frame of execution. This means that there is a very specific order of execution with these tests, which is good for testing, but probably isn't 100% accurate.
Flash Player appears to delay all loads by at least one frame, even loads that are coming from disk which should load immediately. I don't know if this is intentional or not, so I don't want to implement a load delay just for the sake of making tests pass. Ergo, I'm loosening the tests to just test the ability to load and unload movies, and fire events from a loader.
Specifically:
1. `mcl_loadclip` no longer traces out frames of the parent timeline
2. `unloadmovie` et. all use a target movie that doesn't fail the test until 10 frames have passed.
If someone can find a movie network that breaks with fast loading, then I'll consider implementing explicit frame delays for async tasks. Otherwise, this is how we're testing this.
Interestingly, this constitutes an implementation of `AsBroadcaster`. It appears Macromedia decided to implement event handling on `MovieClipLoader` in a very similar fashion to `AsBroadcaster`, down to invoking `broadcastMessage` and searching a `_listeners` property for listeners.
This allows the formation of `'static` futures that can still interact with a player. Async code will need to upgrade the weak reference in order to be able to interact with the player.
David Wendt