Attempting to do so results in borrow-mut panics. Furthermore, it's unnecessary; the handle provided to this function is already derived from the bitmap data in this way.
Since forking isn't an option in Rust (and is generally unsafe, incompatible with threads, and more or less not UNIX's best design idea) we instead grab the current binary path and run it again with a different subcommand.
This should allow us to grab all the panics, including uncatchable ones.
Note: this also requires that we introduce an IPC mechanism. I currently decided to have it spit out CSV rows, same as the main `scan` command. This also makes the psuedo-fork subcommand arguably useful on it's own as it will dump timing metrics for each step.
This relies on a proposed serial bridge as per https://github.com/rayon-rs/rayon/issues/858. As that project is licensed the same as Ruffle itself and the submitter intended it to be included in Rayon, I believe it's legal to copy this code.
Rayon's default of 2MB is about half of what the AVM1 recursion limit requires, and I have plenty of memory, so I might as well add some padding for long runs.
This currently fails to scan the entire Flashpoint `localflash` directory because Rust considers stack overflow to be an immediate program termination, no ifs, ands, or buts about it.
`document.currentScript` works only while the script is initially
being processed. This means that when `publicPath()` was called from
a non-global scope, it failed to detect where ruffle.js is located,
which in turn failed to determine the .wasm location.
Use wasm-bindgen's built-in loader instead of relying on Webpack.
In order to still respect the `publicPath` config, set
`__webpack_public_path__` just before fetching the WebAssembly module.
This allows to no longer declare `.wasm` files as resource assets in
each `webpack.config.js`.
This simplifies the `publicPath` function and makes it useable inside
`fetchRuffle`.
Assuming `publicPaths` isn't used anywhere, this shouldn't be harmless.
`get_local` is basically equivalent to `get_local_stored` that also
handles virtual getters. So instead handle virtual getters in
`search_prototype`. This allows to inline the `get_local_sub` helper
methods into the implementations of `get_local_stored`.
The remaining usages of `get_local` were not exactly correct as they
all should ignore virtual getters. This change solves this as well
by using `get_local_stored` that ignores virtual getters.
It seems like Flash stores sound transform values in 30-bit unsigned integers:
* Negative values are equivalent to their absolute value.
* Specifically, 0x40000000, -0x40000000 and -0x80000000 are equivalent to zero.
Pull out the audio mixing code from desktop and add it to core.
This will allow other backends to use it (such as the web audio
backend) to get consistent audio across all platforms.