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.
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.
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`.
The previous approach of `paths-ignore` was flawed because currently
it doesn't interact well with GitHub's "Require status checks to pass
before merging" setting. As a result, PRs that didn't trigger all
workflows couldn't be merged, because GitHub waited for the skipped
workflows to finish.
`dorny/paths-filter` is a somewhat elegant workaround proposed in
https://stackoverflow.com/questions/66751567.
* dev: run workflows only if certain file paths change
* fix: looks like you can't ? a /
* feat: simpler approach
Don't run Rust if only package.json, package-lock.json or anything under
web/packages has changed.
Don't run either if they only have docs changes.
Adrian Wielgosik