This was added in fecb981 to workaround an issue with additive
alpha color transforms in Firefox. This seems to have been fixed
and is no longer necessary, so Firefox can use the normal code
path.
Guarantee bitmap data after decoding has the expected length for
the given width+height+format. This eases the burden from backends
to worry about this. Pad or truncate the data if it doesn't have
the expected size.
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.
They're now unused thanks to #6975.
Also remove the `crate-type` field from `Cargo.toml`. I'm not sure
exactly what it does and why it was introduced, but seems working
without it.
The web build script in `core\package.json` sets the `RUSTFLAGS`
env var, which overrides any settings in `.cargo/config.toml`.
Add `-Aunknown_lints` to these `RUSTFLAGs` to squelch a stray
`unused_macro_rules` warning.
Remove the `ImageElement` data path for storing bitmaps, as the
asynciness of this is difficult to manage when we need to render
bitmaps immediately. This code path was only being used for JPEG
images that could be decoded by the browser (no alpha).
Instead, always use canvases for bitmap storage. This simplifies
the code and solves some issues with bitmaps not being rendered
properly, although it is likely a little slower toe decode these
JPEGs on the Rust side.
Most gradients are "simply transformed" and can be rendered
directly using canvas commands. But even for complex transforms,
we can push the gradient's transform to the canvas, then
un-transform the path using the inverse of the gradient transform.
Due to various quirks of how timeline-initiated symbols interact with AVM2, it is possible for user code to gain a reference to uninitialized objects (especially `SimpleButton` which doesn't initialize until after `exitFrame`). It is still possible to attach event handlers to them that fire correctly, and movies expect to be able to.
Internal function calls such as `toString` and event handlers
always used the base clip from the function itself, so add an
`ExecutionReason::InternalCall` to signify this and pass it along
to `call_method`.
Fix various scope behavior when executing a function:
* For function calls in SWFv6+, functions are proper closures and
close over the SWF version, base clip, and scope of their
defining function.
* Function calls in SWFv5 are not closures, and use the version,
base clip, and scope of `this` when the function is called.
Fixes#5502.
Testing under Flash shows that methods can be considered 'unchecked'
(allowing them to be called with more arguments than declared
parameters) even if they have a declared return type.
This is relied on by SteamBirds, which registers an event handler
which takes 0 parameters and an explicitly declared return type
This was recently added in https://github.com/rust-lang/rust/pull/96150
Some of the `__version` rules are currently unused, but I assume
that we still want to keep them for potential future use.
This module is now mostly empty, so move the items up to `globals`.
`getDepth` was the only shared method, so declare this property
inline in each display object type. `Video` was also incorrectly
declaring `getDepth`.
Remove `_root`, `_parent` and `_global` from `MovieClip.prototype`.
Instead, these are "magic" properties similar to `_x` and `_y`.
Add `StageObject::resolve_path_property` to handle these, alongside
the `_levelN` property.
Fixes#768.