Reverts #7267
The image tests for the upcoming 'DisplayObject.stageRect' support
differ between Linux and Windows, so we need this support again.
To avoid the Linux filename churn that we previously encountered,
we now only include the platform and graphics backend in the filename
(e.g. `expected-linux-Vulkan`). This may result in some unexpected
'mismatched image' test failures if GHA updates to a version of Lavapipe
that changes rendering output, but this should be relatively easy to
notice.
This PR implements the `Loader.load` method, as well as
the associated `LoaderInfo` properties and events.
We can now load in an external AVM2 SWf: it will be added
as a child of `Loader` object, and will render properly
to the screen.
Limitations:
* The only supported `URLRequest` property is `url`
* `LoaderContext` is not supported at all - we always use the default
behavior
* Only `Loader.load` is implemented - we do not yet support unloading.
* We fire a plain 'Event' for the 'progress' event, instead of using
the (not yet implemented) 'ProgressEvent' class
The main changes in this PR are:
* The AVM2 `Loader` class now has an associated display object,
`LoaderDisplay`. This is basically a stub, and just renders
its single child (if it exists).
* `LoaderStream::Stage` is renamed to `LoaderStream::NotYetLoaded`.
This is used for both the `Stage` and an 'uninitialized'
`Loader.contentLoaderInfo`. In both cases, certain properties throw
errors, while others return actual values.
* The rust `Loader` manager now handles both AVM1 and AVM2 movie loads.
Each render backend keeps track of a stack of BlenModes,
which are pushed and popped by 'core' as we render objects
in the displaay tree. For now, I've just implemented BlendMode.ADD,
which maps directly onto blend mode supported by each backend.
All other blend modes (besides 'NORMAL') will produce a warning
when we try to render using them. This may produce a very large amount
of log output, but it's simpler than emitting each warning only once,
and will help to point developers in the right direction when they
get otherwise inexplicable rendering issues (due to a blend mode
not being implemented).
The wgpu implementation is by far the most complicated, as we need
to construct a `RenderPipeline` for each possible
`(BlendMode, MaskState)`. I haven't been able to find any documentation
about the maximum supported number of (simultaneous) WebGPU render
pipelines - if this becomes an issue, we may need to register them
on-demand when a particular blend mode is requested.
Based on the work in #6717, plus additional adaptions mentioned in
https://github.com/gfx-rs/wgpu/blob/master/CHANGELOG.md#wgpu-013-2022-06-30,
and more not-mentioned but required changes.
Also bump `wasm-bindgen` to `0.2.81` (along with its helper crates), as
required by the new `wgpu` version.
Note that I don't fully understand some of the required changes, notably:
* `wgpu::PresentMode::Mailbox` no longer works on my machine (Windows 11) -
The `wgpu` documentation says that `wgpu::PresentMode::Fifo` is the
only guaranteed to be supported, so I switched over to it instead.
* `self.staging_belt.recall()` doesn't return a `Future` anymore -
I assume it became synchronous so I simply removed the `executor`
from there.
Per https://doc.rust-lang.org/cargo/commands/cargo-test.html#manifest-options,
`cargo --locked` assumes that `Cargo.lock` is up-to-date, and otherwise
exits with an error.
Besides the nice validation, this might hopefully speed-up CI a bit.
This could be done on Web as well, but I'm not sure what's the best
way of doing it.
There seems to be no good reason for testing on Node.js other than
the current LTS. Moreover, npm@6 has a wontfix issue when upgrading
to 8.4 on Windows, which requires a complex workaround: https://github.com/npm/cli/issues/4341#issuecomment-1040608101.
So avoid it by simply not supporting it.
Per https://github.com/actions/virtual-environments/issues/4856,
`windows-latest` will default to `windows-2022` soon (not later than
March, 6). Since it seems like we still run on `windows-2019`, force the
migration by specifying `windows-2022` explicitly.
Since https://github.com/actions/virtual-environments/pull/5050 is
merged, this should fix the failing Web tests on mismatched Chrome and
chromedriver versions.
TODO: Once `windows-latest` defaults to `windows-2022` (again, March, 6),
change back to `windows-latest`.
Upgrading to npm 8.4 on Windows is currently broken: https://github.com/npm/cli/issues/4341
This was avoided by disabling tests on Windows Node 14 in #6167.
Re-enable them by staying on npm 8.3 instead.
Move the `if` condition that tests for the Ruffle official repository
to the job-level, so all steps of that job are skipped, rather than
only the publish step itself. This should have a very little effect,
but I just randomly noticed it.
Publish nightly releases as part of the CI, so Ruffle can be easily
integrated into a website using a CDN (such as jsDelivr). It would
also be easier for websites to keep up-to-date, as NPM auto-updates
the `latest` tag to refer to the latest release.
A dedicated `package.json` is used for the published NPM package,
because `ruffle-selfhosted` depends on the private `ruffle-core`
package, which shouldn't be published.
Also, the `version` field must monotonically increase. So Webpack
auto-fills it to be `0.1.0-nightly.YYYY.MM.DD`. This format satisfies
a couple of needs:
* Newer nightly releases should take precedence over older ones.
* Stable releases (e.g. `1.0.0`) should take precedence over nightly
ones.
And enable the module that really uses WebAssembly extensions for the
releases by running the new "npm run build:dual-wasm" command, which
sets the ENABLE_WASM_EXTENSIONS=true environment variable.
`lerna` is a bit stale, and as such it currently has some outdated
dependencies which Dependabot warns on.
Fortunately, npm 7 supports monorepos natively, via "workspaces". So
simply replace `lerna` with this feature. The migration is pretty
neat and requires a very little invervention.
Because Node.js 14 comes with npm 6 by default, upgrade it manually
as shown in https://github.com/bahmutov/npm-install/issues/103#issuecomment-931226602.
The `error-report` label was not being added to error reports
submitted by panics in the web player, despite the `labels` query
parameter in the URL. Users do not have triage/write access to the
repo, which is required by GitHub to add a label to an issue.
Add an issue template for error reports with the `error-report`
label. This template is now added to the issue URL, which
automatically adds the tag regardless of access level.
EmperorBale