Running 'npm run build --workspaces' will run the 'build' script for all
workspaces, even if one fails. Since all of the other workspaces depend
on 'ruffle-core', running them after a ruffle-core build failure just
produces useless errors in the CI logs.
* Take two: Delay reading image back from render backend using `SyncHandle`
This allows us to avoid blocking immediately after a `BitmapData.draw` call.
Instead, we only attempt to use the `SyncHandle` when performing an operation
that requires the CPU-side pixels (e.g. BitmapData.getPixel or BitmapData.setPixel).
In the best case, the SWF will never explicitly access the pixels of
the target BitmapData, removing the need to ever copy back the render backend
image to our BitmapData. If the SWF doesn't require access to the pixels immediately,
we can delay copying the pixels until they're actually needed, hopefully allowing
the render backend to finish processing the BitmapData.draw operation in
the backenground before we need the result.
Now that the CPU and GPU pixels can be intentionally out of sync with
each other, we need to ensure that we don't accidentally expose 'stale'
CPU-side pixels to ActionScript (which needs to remain unaware of
our internal laziness). We now use a wrapper type `BitmapDataWrapper`
to enforce that the `SyncHandle` is consumed before accessing the
underlying `BitmapData.
* core: Skip GPU->CPU sync for source and target BitmapData during draw
* Introduce DirtyState enum
* Revert "ci: Pass a single argument to `test` command"
This reverts commit 34dbeb7702.
* Revert "ci: Fix is_active variable"
This reverts commit 5b55b6e4b5.
* ci: Apply new fix
* ci: Fix typo
Should be setting the env variable to false, not true
* ci: Fix syntax error
This change makes it so that if there is a goto to a specific frame,
then a frame script is registered for that frame, and then a goto to the
same frame again, the frame script will not be skipped. At least one movie
appears to depend on this behaviour.
Previously we were removing the first occurrence of the invalid
0xFFD9FFD8 byte sequence in JPEG data, but this would break the
JPEG if it happened to contain this byte sequence elsewhere (for
example, EXIF data). Instead, properly parse the JPEG markers
searching for the invalid marker sequence.
Fixes#8775.
Now that a `Bitmap` always stores a `BitmapData`, we can read the pixels
directly from the `BitmapData`, instead of duplicating them in an
`initial_data` field
AsukaMinato