After a panic, `Ruffle::renderer_debug_info()` cannot be called since
it tries to immutably borrow the underlying `Player`, but `Ruffle::tick()`
already holds it mutably.
As a fix, simply use the `_cachedDebugInfo` which is fetched in
advance, before any panic occurs. Rename it to just `rendererDebugInfo`
(without "cache" in its name), because now it's mandated.
wgpu requires buffer copy sizes and offsets to be 4-byte aligned.
Unfortunately, ActionScript can perform 2-byte aligned uploads
into an IndexBuffer3D.
To support this, we now keep a copy of the IndexBuffer3D on the CPU.
When performing an upload to the buffer, we round the offset down
and the size up to the nearest 4-byte aligned value. The cpu buffer
is used to fill out the write with existing data, so that we don't
corrupt the contents of the GPU buffer.
To avoid introducing a new RefCell, I've changed IndexBuffer3D
to use a `Box` instead of an `Rc` to store the trait object.
This allows us to pass a mutable reference down to the backend.
Early class construction is tricky - `Object` defines properties
that need to get copied into subclass instance vtables, but `Class`
defines `prototype`, which needs to be copied into the *class* vtable
of `Object`.
To accomplish this, I've split out instance vtable initialization
into a separate `init_instance_vtable`. We call
`object_class.init_instance_vtable` before
`class_class.init_instance_vtable`, but do things in the opposite
order for `into_finished_class` (`class_class.into_finished_class` is
called before `object_class.into_finished_class`)
Upon panic, `Ruffle::destroy()` attempts to mutably borrow the
thread-local `instances`. However, when a panic occurs, `instances`
is already immutably borrowed by `Ruffle::with_core_mut()`. This
causes the cleanup logic in `Ruffle::destroy()` to be skipped
altogether, and as a consequence the animation handler continues
to be fired, ultimately failing to borrow `instances` repeatedly.
Each time a borrow fails, a console error is logged.
Fortunately the fix is extremely easy - `Ruffle::with_core{,_mut}`
used to `drop(instance)` before running any potentially-panicking
logic, exactly for the reason explained above. But those functions
don't `drop(instances)`, which is subject to the same double-borrow
risk. So as a fix simply add `drop(instances)` in both functions.
With this fix, "Unable to lock Ruffle core" is logged on panic only
twice. These logs require further research, and will be avoided in
a future PR.
relrelb