projects with many image assets initially load with question marks

[benjiwheeler]

Expected Behavior

1. load a project with a high number of images, such as https://scratch.mit.edu/projects/697304342/
2. click the green flag
3. see the costumes normally
4. project runs at normal speed

Actual Behavior

3. some costumes appear as question marks
4. project runs incredibly slowly

System Details

Unclear if this is system/browser dependent; I'm using an M1 mac running chrome 103

Discussion

One of our devs said "I'm not sure why it happens. It seems to be related to loading MANY assets. Often, if you reload the project it'll load more of the assets successfully (I assume the browser cache is helping) and after an iteration or two it might get to 100%."

I tried loading https://scratch.mit.edu/projects/697304342/, and it loaded with many question marks and ran incredibly slowly -- like 1/20th its intended speed. I then tried reloading it twice more, and on the third load, everything seemed to finally load completely, and the project ran fast.

Notably, the project works fine on the first load with Turbowarp: https://turbowarp.org/697304342 -- perhaps we should ask them what they're doing differently?

One possibility: we might be hitting a limit for parallel web requests. We don't currently do anything to throttle asset requests -- the editor throws every asset request to scratch-storage, and scratch-storage makes a fetch request immediately. We rely on the browser to schedule (throttle) these requests.

In scratch-desktop, where those are actually file loads instead of web requests, that ends up destroying performance in some cases, like the asset library display. We had to add throttling in that case, but that throttling implementation is specific to the asset libraries.

Maybe moving that throttling into scratch-storage would help with performance and possibly fix this ERR_INSUFFICIENT_RESOURCES thing. It would also be a step toward merging the different branches of scratch-gui, which is another long-term goal of ours.

[apple502j]

Duplicate of #5844, #7111 (behavior probably changed with recent VM/storage fixes)

[benjiwheeler]

Closing per #7111