avm1: Display objects are indirectly referenced by string path (fix #1513)

[Herschel]

Proof-of-concept of changing avm1::StageObject to reference its display object via string path instead of GcCell. This is the last big gotcha to tackle in AVM1, so making a rough draft to gain an understanding of the behavior. Let's hold off on merging this until after #5339.

Display objects in AVM1 should not actually hold pointers to their linked display object, but instead refer to it indirectly via absolute string path (for example, _level0.clip.foo). See https://moock.org/asdg/technotes/movieclipDatatype for more info.

This means:

• Every property access on an AVM1 display object requires dereferencing the path to grab the actual display object.
• If that display object is removed from the stage, the AVM1 object still exists, but the the path no longer resolves to a display object, so the reference is "dangling". Any operations on the AVM1 object are noops.
• If a display object with the same path is later added to the stage, the AVM1 object will once again resolve, and all operations will work using the new display object.

Every movieclip property access clip.foo now requires a full resolve of the path, so this could significantly hurt performance -- measurement is needed.

TODO:

• Properly handle unload events (avm1: Unload clip event handlers should cause clips to be destroyed later #1535).
  • Currently onUnload tests fail because the path no longer resolves.
  • Clips with unload handlers should switch to "off-screen" depths (<0), which allows them to continue to exist for an extra frame.
• Remove base from StageObject and instead change the DisplayObject::object into a ScriptObject/PropertyMap?
  • We have to resolve the path to a display object for every operation, so it makes sense that doing so should grab the base ScriptObject from the display object itself.
  • Forward gets/sets/other methods to this ScriptObject after dereferencing the path.
  • Test how watches etc. work on movieclip objects after removing + replacing a clip with the same path.
  • Be careful that prototype, interfaces etc. work correctly.
• Add tests
• Investigate performance and potential optimizations.
  • Having benchmarks would be helpful.
  • Idea: StageObject::path could store the parsed path segments instead of full string. Something like { level: Depth, segments: SmallVec<AvmString> }.
  • The Big UTF16 String Rewrite #5339 will help a lot; eventually will let us cache string hashes, etc.

Fixes #993, #1017, #1029, #1114, #1140, #1415, #1513, #3839, #3916, #4404, #4793, #5275, others...

[Toad06]

Awesome! This also seems to fix #5277 and Hellbound (the character was "stuttering" in the air after losing a life).

But there's a regression in Steppenwolf 5-1. The game softlocks when you try to climb the rope. The following messages are logged in the console:

SetTarget failed: _parent not found
Target not found: Target="_parent" Base="_level0.Corde.instance1611"
NextFrame: Invalid target

Could this be related to #5502?

[ousia]

@Herschel, this PR will help to solve at least 22 issues.

I mention this, just in case it could be finished and merged.

[ousia]

Many thanks for your help and your excellent work.

[ousia]

@Herschel,

just some comments that might help to consider finishing this PR.

1. By the end of Agust, three related issues would have been reported for two years.
2. By the end of this year, other five related issues would be added to that list.
3. Since opened eight months ago, this PR has been steadily mentioned in other issues every month.

Many thanks for your excellent work.

[Aaron1011]

Once #7254 is merged, this should fix a bug in FancyPants2 where the player gets frozen in midair.

[ousia]

Excuse me for asking this obvious question, this is an important issue in AVM1.

Is there any ETA for the merge of this PR?

[CUB3D]

This branch doesn't build anymore due to a borrowing issue, so I rebased this up to ~Nov to be able to test with it, see https://github.com/CUB3D/ruffle/tree/avm1-mc-string-ref

This also seems to fix #2840

[ousia]

@Toad06, does the regression mentioned in #5492 (comment) happen after the merge of #5502?

I wonder whether this PR may be merged when it doesn’t break anything.

I know that this isn’t ideal, but it will help to fix particular issues after the merge.

Happy New Year to everyone!

[relrelb]

Superseded by #9447.