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 code was always wrong; and only saved from breaking by other wrong code elsewhere. Specifically:
* `SimpleButton.construct_frame` sets the wrong initial state
* but `MovieClip.instantiate_child` fires frame events before `post_instantiation`
* and `SimpleButton.post_instantiation` sets the correct state
This works now because all object placement and removal happens in `enter_frame`. Constructing those objects right away causes them to drop added events.
We cannot remove other instances of `construct_frame`, however - those are in places where we actually do expect constructors to run, not just see things get placed.
This also centralizes all the code we added in the prior commit into `on_construction_complete`, which should be called whenever an AVM2 object finishes construction.
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
Usage of TObject::as_script_object was always followed by an unwrap, and
only SuperObject returned None.
The name change is intended to make clearer the fact that using the
returned object may bypass special behavior.
* tests: Add a test for issue #8630
* core: No-op gotos in AS3 do not actually do anything, even though they emit events
Fixes issue #8630
* tests: Add more tests for various #8630-adjacent cases
* tests: Ignore the tests with script removal as they expect MovieClip children to be nulled upon removal
* chore: Case sensitive filesystem fix
Co-authored-by: Adrian Wielgosik <adrian.wielgosik@gmail.com>
`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>
This is done by:
- using the global constant pool instead of a fresh empty one:
- OK, as no call-site is directly executing arbitrary bytecode that
could care about the contents of the constant pool.
- pre-allocating the global scope object in the `Avm1` context
- using the global scope directly instead of allocating a local scope:
- OK, because no call-site is directly defining locals on the
returned Activation's scope.
Currently, we rely on ShapeTessellator being able to get a BitmapHandle
without a RenderBackend. With the upcoming BitmapData refactor,
we will always need a RenderBackend to get a BitmapHandle, which creates
borrow-checker issues in ShapeTessellator (which is stored in a
RenderBackend).
To solve this, we split BitmapSource.bitmap into two methods -
BitmapSource.bitmap and BitmapSource.bitmap_handle. ShapeTessellator
continues to use BitmapSource.bitmap, and uses the u16 bitmap id
instead of a BitmapHandle. The BitmapSource.bitmap_handle method
is used inside each render backend to convert the id to a BitmapHandle,
avoiding borrow-checker issues.