This basically reverts #5737 and #6458 for the WebGL backend, which
regressed a bug where setting the style `display: none;` to a Ruffle
player logged many WebGL warnings to the console. This happened
because `renderbuffer_width` and `renderbuffer_height` were set to zero,
leading to problems when trying to pass them to WebGL APIs.
Avoid such situation by ensuring that `renderbuffer_width` and
`renderbuffer_height` are at least `1`, exactly as done before.
Also add a comment that explains why `.clamp()` isn't used.
Fixes#1264.
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.
* Remove `BitmapDataStorage` as its no longer necessary, and store
the bitmap canvas/context in `BitmapData` instead.
* Store the `Bitmap` RBGA buffer in the canvas backend. Previously
this was thrown away when converted to `ImageData`, but this
causes the glitchy pixels mentioned in:
https://github.com/ruffle-rs/ruffle/pull/6975#issuecomment-1127942520
`ImageData` does not copy the buffer passed to it, so store it
to keep it alive. See:
https://github.com/rustwasm/wasm-bindgen/issues/2445
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.
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.
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.
dependabot[bot]