This makes `Bitmap` delegate to `BitmapData` for
all of the bitmap-related information (handle, width, and height).
As a result, we now unconditionally store a `BitmapData` in `Bitmap`.
As a result, swapping the underling `BitmapData` instance will
automatically change the properties (and rendered image) of a `Bitmap`.
This required some refactoring in the render backends in order to
get access to a `BitmapHandle` through `BitmapData`.
In future versions of `gc-arena`, the `Debug` impl. of `Gc`
and `GcCell` will print the pointed-to value, which will cause
derived `Debug` impls. to enter an infinite recursion.
As such, this manually implements `Debug` on types wrapping a
`Gc/GcCell` to maintain the current behavior.
Previous behaviour defaulted to undefined and applied the format to the
range [0,0) instead of defaulting to -1 and applying the format to the
full length of the TextField.
This has a few other knock-on effects:
* AVM2 added-to-timeline events are fired by each object after it constructs its AVM2 side. This is opposed to before when we fired them after object instantiation and placement. This also gets rid of a prior hack we had for the AVM2 root movie getting added to the stage - or, more accurately, adopts it for everything.
* The supercall constructor for `DisplayObject` runs `construct_frame` on all children. This matches Flash Player behavior.
NOTE: This currently breaks the `placed_with_name` check, so there's going to be a lot of spurious can't set warnings
`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).
We only called `get_bitmap_pixels` when creating a `BitmapData`
for an SWF-provided `Bitmap`. We now store the initial pixels
in `Character::Bitmap`, and use them to initialize a `BitmapData`
when needed.
This lets us simplify the wgpu backend, which no longer needs
to store a `Bitmap` object. In addition to saving space for
`BitmapData` objects that lack an SWF `Bitmap`, this will make
it easier to move data from `bitmap_registry` into `BitmapHandle`
itself.
D.O.s removed by the timeline may only be removed from the depth list
(if they were manipulated by AS3 scripts), but their unload method
would still be called, which is wrong.
This is linked to the legacy DisplayObject::Text, which can
only be created by Flash CS6 (but is allowed in AVM2 swfs).
The 'StaticText' class cannot be constructed from ActionScript.
To support this, I've added support for native initializers to
playerglobal. This allows us to throw an exception in the
ActionScript constructor in Test.as, and do nothing in the native
intiializer (so that we can construct it from a DisplayObject).
I've left StaticText.text unimplemented for now, since it will require
dealing with Glyphs
Co-authored-by: kmeisthax <dcrkid@yahoo.com>
The call to `super_init` will initialize a `DisplayObject` (if unset)
in the `Sprite` constructor, using exactly the same logic that we're
attempting to use. The code in `MovieClip` is unreachable, and can
be deleted.
These methods were incorrectly treating the argument as a local name,
instead of a qualified name. Additionally, 'getDefinition' now throws
an AVM error.
Previously, we would display an empty string for the method name.
We can now store a `&'static str` again in `NativeMethod`,
instead of needing a `Cow`
Instead of propagating the underlying compression library errors.
Also, make `ByteArray.deflate` and `ByteArray.inflate` pure-ActionScript
methods that call into the native `ByteArray.compress` and `ByteArray.uncompress`
native methods, respectively.
And make it generic, as a first step towards making it a general-purpose
data structure for the whole codebase. Some potential replacements are:
* `BoundingBox` in `render/src/bounding_box.rs`.
* `BoxBounds` in `core/src/html/dimensions.rs`.
* Parameters to a bunch of `BitmapData` methods in
`core/src/bitmap/bitmap_data.rs`.
Now that we have a custom `Error` enum, this is very straightforwawrd.
I've converted `getDefinitionByName` return an AVM error, since this
is commonly used by games to test for a class.
While doing this I also noticed that we were incorrectly producing AmfValue::Integer if our
target AMF version is AMF0. This is incorrect because AMF0 is based on AS2, which does not
recognise Integer as a valid type, and therefore must be represented with Number instead.
This requires estimating a count of bytes loaded of the original compressed stream, even though we only have uncompressed byte totals at this point. I instead rescale the uncompressed bytes by the compressed count to roughly estimate what would be the `bytesLoaded` had we been actually streaming bytes in and preloading them synchronously.
An "empty clip" is any clip created by the `new` or `new_with_avm2` function, intended for dynamically-created movie clips with no association to a movie symbol.
Nathan Adams