When ActionScript uses a ByteArray/Vector.<Number> as a shader input
or target, we create a temporary Rgba32Float texture, and copy the
input float32 bytes to/from the texture.
Unfortunately, wgpu doesn't seem to support an Rgb32Float (3-channel)
texture. When the shader uses 3 channels, we use a Rgba32Float
(4-channel) texture, and manually insert/remove padding for the
alpha channels. This isn't very efficient, but it's the simplest
solution.
The temporary textures themselves aren't cached anywhere - if this
becomes a performance issue, we could look into using some of our
existing wgpu texture/buffer pooling code.
We now validate the passed in profile, and return the selected profile
from 'Context3D.profile'. We don't yet alter the available
registers/textures based on the profile.
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.
* wpgu: Initial implementation of PixelBender shader execution
The implementation is split across four crates:
* `ruffle_render` now holds the main PixelBender bytecode parsing
implementation (previously, this was in `ruffle_core`).
* `ruffle_core` holds some helper functions for converting between
AVM2 `Value`s and the PixelBender vector types.
* `naga-pixelbender` (newly created) constructs a Naga `Module`
from parsed PixelBender bytecode
* `ruffle_render_wgpu` sets up the render pipeline for the shader
constructed by `naga-pixelbender`, and actually executes the shader.
The Actionscript-side shader parameters are passed in through uniforms.
This allows us to cache the compiled `naga::Module` and associated
wgpu types inside `ShaderData`, when it's first created. Each invocation
of a `ShaderJob` only needs to create a bind group and render pass.
Limitations:
* Only a few of the PixelBender opcodes are implemented - however, this is
enough to get Stemlands cannon rotation working, as well as a cool
"donut" shader that I found and included as a test.
* PixelBender matrix types are not supported.
* Only BitmapData is supported as an input/output type - Flash Player
also supports using Vector and ByteArray
* ShaderJob execution is always synchronous.
* Adjust comments
* Address review comments
Generally, when transforming a difference between two points, `p1`
and `p2`, with a matrix `m`, we would like the following property
to hold:
```
m * (p1 - p2) == m * p1 - m * p2
```
Unfortunately, it wasn't like this before, because matrices have a
translation component, which is non-linear. In `m * p1 - m * p2`,
the translations of `m * p1` and `m * p2` are the same and therefore
cancel out each other. However, in `m * (p1 - p2)` the translation
stays.
In order to preserve this property, introduce a new `PointDelta`
type which is not subject to translation when transformed by a matrix.
For now, the following operations are supported:
* `Point - Point -> PointDelta`
* `Point + PointDelta -> Point`
* `Point += PointDelta`
* `Point - PointDelta -> Point`
* `Point -= PointDelta`
As a consequence, the expression `position + global_to_local_matrix * mouse_delta`
in `update_drag()` now ignores translation, which fixes#817.
This matches the Context3D docs. Calling 'present' swaps
the buffers.
I wasn't certain if we actually need a double-buffered depth
texture, but I included one just to be safe.
Now that most of the complicated Context3D methods have been
implemented, we can simplify the overall design. Instead of queueing
up commands and having `present` execute them in a loop, we
can execute each command immediately. The key insight is that
a `RenderPass` is only needed for `DrawTriangles`, so we don't
have to store it in `Context3D` and deal with complicated lifetime
issues.
The old behavior gave us implicit double-buffering behavior,
since nothing would get rendered until a 'present' call.
Now that a 'drawTriangles' call will immediately submit
a draw command, we need to implement actual double buffering.
This is done in the next commit.