The async extensions loading counter is not the most reliable thing,
so let's not break block sharing if something went wrong.
This reverts commit 042f979d59.
This adds a new mode of custom extension that runs outside of any
sandbox -- they're just <script> tags. This is disabled by default and
needs explicit opt-in. Documentation will be written later.
This also will save the URLs of the loaded custom extensions to
project.json when serializing a project. When deserializing a project,
this list can be read to automatically load the extensions. This, again,
is disabled by default and requires explicit opt-in.
A new mechanism called the SecurityManager was added to the extension
manager to facilitate these new features. This replaces workerMode and
is a breaking change.
Various other custom extension related changes were also added:
- Reject invalid URLs in loadExtensionURL
- Various cleanup and refactoring
Was disabled because hidden monitors are not actually removed from the JSON,
which cause issues when loading the project in vanilla Scratch. We have fixed
that issue in the previous commit.
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.
GarboMuffin