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.
The bind group layout only depends on the texture registers
(and 2D/cubemap type) accessed by the fragment shader, not on
the runtime texture bound with Context3D. This means that we can
build and cache it when we compile the AGAL program to a Naga
module.
Since the bind group layout is used for the overall pipeline, I've
refactored the shader caching code into `ShaderPairAgal`, which
holds both the vertex and fragment shader bytecode, and compiles
both in the `compile` function.
When using a 'Loader', properties on the 'contentLoaderInfo' become
set during specific events in the load sequence. In particular,
'LoaderInfo.bytesTotal' becomes available during the first 'progress'
event.
Also, 'LoaderInfo.parameters' is now properly set from the URL query
parameters. In Flash player, this work even with filesystem urls
(e.g. 'file:///some/path/to/file.txt?paramOne=valOne' will load
a file named 'file.txt', setting and expose the parameter 'paramOne'
with value 'valOne' in `LoaderInfo.parameters`). This required some
cleanup to the desktop and test NavigatorBackend impls to strip
out query parameters when loading a parameter from disk.
Previously, we would set `SwfMovie.parameters` manually from the url.
Now, the various `SwfMovie` constructors automatically extract
query parameters from the provided url. Outside of `SwfMovie`,
we only append *extra* parameters (e.g. those set from `flashvars`).
This makes CPMStar ads work, since the loaded SWF needs to access
`LoaderInfo.parameters`
The 'winding' argument and filling behavior described in the docs
are not yet implemented. However, this implementation is good enough
for Scratch to render its default cat image.
We were previously only ever checking children,
and not attributes.
In order to avoid matching both attributes and elements
with a given name in 'descendants', `E4xNode::matches_name`
now checks `is_attribute` on the provided `Multiname`. This
requries changing several other parts of the codebase to
properly set this flag on `Multinames` provided by ActionScript.
The only generic class is `Vector`, which only has a single parameter.
However, we currently store a list of type parameters in several places,
which requires redundant checks that the list only has one entry.
Instead, we now store an `Option` everwhere except for
`swf::Multiname::TypeName` (since the actual SWF format supports
multiple type parameters). We still perform the same check when loading
bytecode (the swf Multiname should only have at most one type
parameter), but the rest of the codebase can deal with an `Option`
instead.
In the special case where y_min==y_max==(height-1),
we would create a bad 'encompassing' region - subtracing
one from the max would make it smaller than the min,
causing `PixelRegion::encompassing_pixels` to treat it
as the minimum, and add one to `height - 1`
There's no work to do when x_min==x_max or y_min==y_max,
so we can also skip the sync and GC write in this case.
This works a bit differently from SWF videos, we do not retain decoded video frames or valid seek points indefinitely. This assumes code interacting with `NetStream` is at least mildly aware of how a video codec is supposed to work and what the performance implications of that are.
michiel2005