The original link is not working anymore so I put a link to the wayback machine in it's place that leads to the original document
Co-authored-by: Adrian Wielgosik <4729533+adrian17@users.noreply.github.com>
`tag_length` isn't really necessary since each tag is read using
a dedicated `swf::Reader`, which keeps track of the tag boundary
internally.
As a result, `tag_len` can be avoided passed around many times in
`movie_clip.rs`.
Newest Flash Player exits on unknown value types. However, older versions
(at least FP9) just ignore them and continue to the next value.
Follow the lenient behavior in order to support more content (e.g. #8389
doesn't work on newest Flash Player).
Fixes#8389.
And make it generic, as a first step towards making it a general-purpose
data structure for the whole codebase. Some potential replacements are:
* `BoundingBox` in `render/src/bounding_box.rs`.
* `BoxBounds` in `core/src/html/dimensions.rs`.
* Parameters to a bunch of `BitmapData` methods in
`core/src/bitmap/bitmap_data.rs`.
In several cases, the current code seems preferable to the
code required by `clippy::bool_to_int_with_if`. Let's suppress
this for now to get the build passing, and decide later if this
is something that we want to enable.
The SWF19 specs incorrectly state DefineEditText tag only contains
font height if the HasFont flag is set. The tag also contains
the height if the HasFontClass flag is set. This indicates that a
font is used via runtime sharing.
Extract `swf::Reader::read_do_abc()` which, as the name suggests,
reads a `DoAbc` tag, and use it before calling to `Avm2::load_abc`.
Finally, introduce `DoAbcFlag` using `bitflags`.
This greatly simplifies the ABC loading code.
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.
dependabot[bot]