We now do this in scratch-parser instead.
Moving it to scratch-parser allows the alternative parser to run on
projects loaded from compressed files in addition to JSON projects
Browsers, especially Chrome, crumble when we try to create too many
image bitmaps at once. So we'll queue them up when too many are
happening. Projects will load slightly slower but this is still much
faster than <img> with data: URIs
Reverts 7abbcdbb10
I am unable to reproduce the claim that ImageBitmap uses more memory
than <img>. Instead I've observed the following:
<img> uses a base64 data: URI which is slower than creating a Blob
directly from the binary data. I also experimented using a blob: URI
with <img> and did find it to perform better. A future commit may use
this when createImageBitmap() is not available.
<img> can't be reliably decoded in parallel. Chrome in particular will
very often wait until texImage2d() to actually decode the image, which
turns image decoding into a single-threaded process. Calling decode()
does not affect this. createImageBitmap is reliably parallelized.
<img>'s only benefit is that projects with a lot of copies of the same
exact costume will usually have their image decoding happen only once
whereas createImageBitmap() will decode each one individually (does not
apply when using blob: URIs).
Chrome:
<img> with data: 48.5MB 4160ms
<img> with blob: 48.4MB 2162ms
createImageBitmap() 48.4MB 1261ms
Equivalent SVGs 60.8MB 3857ms
Firefox:
<img> with data: 88.3MB 3704ms
<img> with blob: 88.9MB 2459ms
createImageBitmap() 92.5MB 2380ms
Equivalent SVGs 483.3MB 5429ms
Using a test project with 100 480x360 unique costumes.
Equivalent SVGs is the same project with each costume converted to SVG,
just for curiosity. Note that SVGs may not actually be rendered or
decoded until the project starts.
This fixes a Scratch bug affecting custom extensions.
There were two bugs in the interpreter:
- Thread status wouldn't reset after promise resolves
- Loop finding logic broke on hats and mangled the stack
We now support ScratchX blocks, so the test now fails as it assumes we don't.
The test was modified to use a different invalid opcode that isn't a ScratchX block.
Extends .sb2 importer to convert extension blocks from ScratchX project files
(.sbx) to the format we require.
This doesn't automatically load extensions; they still must be loaded manually.
GarboMuffin