The 'gc_arena' dependency was only used to manipulate the `GcCell`s
containing the vertex and fragment shaders; replacing these by a
reference to a plain old `Cell` means tha the Context3D traits and
types do not need to interact with GC'd object anymore.
As a knock-on effect, we can also remove the `Activation` parameter
from most of the `Context3DObject` methods.
* core: add temporary, ruffle-internal copy of `gc-arena` crate
This will allow bumping the upstream `gc-arena` version while
reexporting our own version of the old `GcCell` API, so that
Ruffle's code can be gradually migrated.
Once the migration is done, this crate should be removed.
* core: bump `gc-arena` to kyren/gc-arena#56
Add back the removed `GcCell` to our internal facade crate
* core: bump `gc-arena` to current master
This bump renames `Gc::allocate` to `Gc::new`
* core: rename `GcCell::allocate` to `GcCell::new`, to match `Gc`
* core: bump gc-arena to (slighly after) v0.3.1
Add typedefs for old `*Context` names in the gc-arena facade crate
* core: replace uses of `CollectionContext<'_>` by `&Collection`
* core: Add `gc()` convenience method for `*Context` and `Activation` types
This allows shortening most instances of `[activation.]context.gc_context`
to `activation.gc()` or `context.gc()` (but not all instances, because of
borrowck) Note that this doesn't actually do these shortenings to avoid
major code churn.
`BitmapHandle` now holds `Arc<dyn BitmapHandleImpl>`.
This allows us to move all of the per-bitmap backend data into
`BitmapHandle`, instead of holding an id to a backend-specific
hashmap.
This fixes the memory leak issue with bitmaps. Once the AVM side of a
bitmap (`Bitmap`/`BitmapData`) gets garbage-collected, the
`BitmapHandle` will get dropped, freeing all of the GPU resources
assoicated with the bitmap.
This PR implements core 'stage3D' APIs. We are now able
to render at least two demos from the Context3D docs - a simple
triangle render, and a rotating cube.
Implemented in this PR:
* Stage3D access and Context3D creation
* IndexBuffer3D and VertexBuffer3D creation, uploading, and usage
* Program3D uploading and usage (via `naga-agal`)
* Context3D: configureBackBuffer, clear, drawTriangles, and present
Not yet implemented:
* Any 'dispose()' methods
* Depth and stencil buffers
* Context3D texture apis
* Scissor rectangle
General implementation strategy:
A new `Object` variant is added for each of the Stage3D objects
(VertexBuffer3D, Program3D, etc). This stores a handle to the
parent `Context3D`, and (depending on the object) a handle
to the underlying native resource, via `Rc<dyn
SomeRenderBackendTrait>`).
Calling methods on Context3D does not usually result in an immediate
call to a `wgpu` method. Instead, we queue up commands in our
`Context3D` instance, and execute them all on a call to `present`.
This avoids some nasty wgpu lifetime issues, and is very similar
to the approah we use for normal rendering.
The actual rendering happens on a `Texture`, with dimensions
determined by `createBackBuffer`. During 'Stage' rendering,
we render all of these Stage3D textures *behind* the normal
stage (but in front of the overall stage background color).
As usual, also bump its helper crates (`js-sys`, `web-sys` and
`wasm-bindgen-futures`) to the latest versions.
Due to https://github.com/rustwasm/wasm-bindgen/pull/3031, use the
`serde-wasm-bindgen` crate as a replacement to the deprecated
`JsValue::from_serde` function.
* avm2: Implement `BitmapData.draw` for `wgpu` backend
This method requires us to have the ability to render directly to a
texture. Fortunately, the `wgpu` backend already supports this in
the form of `TextureTarget`. However, the rendering code required
some refactoring in order to avoid creating duplicate `wgpu` resources.
The current implementation blocks on copying the pixels back
from the GPU to the CPU, so that we can immediately set them in
the Ruffle `BitmapData`. This is likely very inefficient, but will
work for a first implementation.
In the future, we could explore allowing the CPU image data and GPU
texture to be out of sync, and only synchronized when explicitly
necessary (e.g. on `getPixel` or `setPixel` calls).
* Rename `with_offscreen_backend` to `render_offscreen` and use Bitmap
* Don't panic when backend doesn't implement `render_offscreen`
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.
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.
I (Michael R. Welsh) assign to Ruffle LLC all rights, title, and
interest to copyrights of my personal contributions to Ruffle,
effective March 26, 2022.
To avoid PNG-encoding every frame of every video for example.
If it needs to be converted to a base64 "data:" URL anyway,
compute it lazily and cache it behind a RefCell.
Raw pixel manipulation can be done through temporary ImageData objects.
The potential to use an image element is retained, so the native JPEG
decoder of the browser can still be utilized.
Flash always uses the even-odd fill rule, whereas canvas defaults to
nonzero.
Specify the fill rule explicitly in both `swf_shape_to_canvas_commands`
and `swf_shape_to_svg`.
As usual, also bump its helper crates (`js-sys`, `wasm-bindgen-futures`)
to the latest versions, except for `web-sys` which is locked by wgpu
to 0.3.50.
Moulins