We will call this the "before-above" rule, to contrast with the previous "after-below" behavior. The main difference is how off-depth-list children are handled, which more closely matches AVM2.
The previous implementation of after-below wouldn't work unless we made the fallback case of not having a below child put it to the *end* of the list. This gave us test pass but broke animations. The first one I tried, Cirno's Perfect Math Class, prepends the entire depth list, which with the half-broken after-below behavior wound up appending to the render list.
There isn't an inverse problem with before-below and the end of the list, since we cover that case and we don't have to put weird exceptions.
The purpose of this refactor is twofold:
1. Ensure `TDisplayObjectContainer` holds all the container methods we need
2. Ensure that future adjustments to trait methods automatically apply to the display object's own use of the container, in case we want to do things in those methods that can't be done in a borrowed container
There are two places where we cannot use the new trait methods:
1. `Button.set_state` as it holds a borrow at the point we want to clear the container
2. `MovieClipData.goto_remove_object`, since it's a method on the data and thus cannot access trait methods
This particular commit generates a lot of noise as several `DisplayObject` methods were incorrectly marked as non-mutating.
This also changes the underlying `DisplayObjectContainer` method to accept any type of range. Turns out enum trait objects aren't actually trait objects and don't need to worry about object safety!
Depending on how I'm reading the old code I replaced, it appeared to be constructing execution lists backwards. I have no idea if this was intended behavior or not. If so, then I'll need to add reverse-add capability to `replace_at_depth`.
`ChildContainer` is responsible for maintaining child lists for all display objects that can hold children. Currently, this is just `Button` and `MovieClip` since those are the only objects in AVM1 that can have children, but this will be extended to other objects in future commits.
The number of lists managed has also increased from two to three. The execution list is unchanged save for it's migration into the `ChildContainer` struct. The render list has been split in two to support AS3. Specifically, the render list is now a `Vec`. Render children are still rendered in order but they are now referenced by AS3 `id`s rather than depths. The old `BTreeMap` that served as a render list is now the depth list and serves to maintain compatibility with SWF tags and AVM1 code that refers to things on the timeline by depth.
For example, let's say we had two objects on the clip at depths 5 and 6. AS3 would see them as children IDs 0 and 1. Adding something at ID 1 translates to putting something between depth 5 and 6. To do this, we shift all higher-depth children up one depth to make room for the incoming clip, producing a new order of depths 5, 6, and 7.
This fixes a hang in as-of-yet uncommitted AS3 tests that reused display objects, where repeated removals and additions to the same MovieClip caused the construction of a cyclic render list.
David Wendt