Though https://github.com/rust-lang/rust-clippy/pull/8355 has been
merged, it seems to still report false-positives on nightly channel.
For now just fix the instances reported by stable clippy, and keep
`needless_borrow` allowed.
Adjust `common_tess` to add an additional `mask_index_count` to
draws. This is used to not render strokes when drawing a shape as
a mask stencil.
Fixes#7027.
wgpu 0.13 added `Surface::get_supported_formats`, so we can check
if a non-sRGB surface format is supported on the current platform.
Because Flash colors and blending are in sRGB space, we want a
linear surface when possible to prevent the colors from being
fiddled with by the GPU.
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.
Currently, all three render backends hold on texture-related
resources indefinitely (`register_bitmap` pushes to a `Vec`,
and never removes anything). As a result, the resources used
by the render backend (which may include GPU memory) will grow
over time, even if the corresponding `BitmapData` has been deallocated.
This commit adds a new `unregister_bitmap` method, which is called from
`BitmapData.dispose`. All render backs are changed to now use an
`FnvHashMap<BitmapHandle, _>` instead of a `Vec`, allowing us to
remove individual entries.
Currently, we only call `unregister_bitmap in response to
`BitmapData.dispose` - when `BitmapData` is freed by the
garbage collector, `unregister_bitmap` is *not* called.
This will be addressed in a future PR.
Since all `RenderBackend::register_bitmap_*` implementations are
identical now, move them to the default implementation of `RenderBackend`.
Also, turn `RenderBackend::register_bitmap_raw` into `RenderBackend::register_bitmap`,
which accepts a single `Bitmap` parameter.
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.
Always use a non-sRGB texture as the render target so that color
and alpha blending are in sRGB space, matching Flash behavior.
If the surface format requires sRGB, render to an intermediate
linear buffer and copy to the surface as a final render step.
naga is currently lenient about some things which are invalid by
the WGSL spec. The Tint WGSL compiler disagreed, so these shaders
failed to compile in Chrome.
This interface handles returning a bitmap given an ID and is used
by the render backend to get the bitmap used for a bitmap fill.
This will allow for bitmap fills in the drawing API, as these will
manage their own list of bitmaps.
This also removes the MovieLibrary dependency from render backends
and will allow for better decoupling in the future.
Matrices in an SWF file store their scale/skew components in
in 16.16 format (fbits).
Split `ruffle_core::Matrix` and `swf::Matrix`. `swf::Matrix` now
stores its data as `Fixed16` instead of immediately converting to
`f32`.
Use the proper types for ColorTransform:
* Fixed8 (8.8) format for multiplicative component
* i16 format for additive component
This matches the behavior of Flash (for example, alpha only changes
in units of 1/256).