Loading "Bad Apple Animation" by comp09 crashes computer

[towerofnix]

Expected Behavior

The project loads, or the editor crashes at some point; nothing particularly bad happens to the computer.

Actual Behavior

After waiting a little while for the project to load, my computer explodes 💥 locks up; all I can do is restart it by holding down the power button.

Steps to Reproduce

Open comp09's project Bad Apple Animation. 2.0 link is here; 3.0 link follows (copy/paste it): http://llk.github.io/scratch-gui/develop/#117487433

Operating System and Browser

Firefox 58.0 on Debian (testing).

I've got 8GB of RAM if that's relevant, but I'm not really sure what causes this project to fail so badly. Note that this project makes extensive use of very large SVGs (730 costumes, each 1536x1152 pixels large).

[thisandagain]

Thanks for reporting @towerofnix. Edge case examples like this are really helpful.

[towerofnix]

@thisandagain comp09's projects are basically an entire trove of that, then. Definitely have a go at testing them!

[towerofnix]

I tried a comparable project, asdfscratch (also by comp09; 1606 480x270px costumes), in both the 3.0 GUI and the VM. My computer crashed both times. In scratch-vm, 919 assets loaded (roughly half the ~2000 needed, total).

[towerofnix]

Another large project which causes a crash: https://scratch.mit.edu/projects/114926309/ (2.0 link)

This time, my computer only crashed after reloading the project. I'm fairly certain this has to do with available memory; maybe Firefox isn't clearing memory up nicely (or in time to load the many assets all over again).

[towerofnix]

"The Scratch Saga - Part 2.0", by WazzoTV, crashes my computer in 3.0: https://scratch.mit.edu/projects/230402884/

I'd already previously loaded, in the same tab, Astro947RMX's related "Behind The Scenes", which also contains many assets: https://scratch.mit.edu/projects/237125515/

I loaded WazzoTV's project by changing the # in the URL. As mentioned previously, reusing the GUI twice might have to do with it.

Edit: Indeed, loading the project in a fresh GUI (i.e. opening the URL https://llk.github.io/scratch-gui/develop/#230402884 in a new tab) did not cause a crash.

[as-com]

I was going to file an issue for this exact project... and you beat me to it! :P

On Safari/macOS Mojave, the tab consumes more and more RAM until Safari kills it before it finishes loading.

[as-com]

I just tried testing this in a Windows VM (12 vCPUs, 16 GB RAM) on my server...

The tab crashed shortly after I took this screenshot. Let me assign this VM more RAM...

[as-com]

I upped the memory of this VM to 80 GB, and I finally got the project to run!

Scratch's new system requirements:

• Six core CPU at 2 GHz
• 32 GB of DDR4 memory (the DDR3 memory in this server seemed to be a bottleneck)
• Dedicated graphics card (software rendering was slow)
• Firefox (Chrome crashes before available memory can be consumed)

It is left as an exercise for the Scratch team to profile the memory usage.

[AmazingMech2418]

@as-com One problem. Not everyone has Firefox. Also, the other system requirements aren't very good... Devices like chromebooks would completely fail to load anything. I know quite a few Scratchers who can only use chromebooks for coding. This needs to be fixed.

[towerofnix]

@amazinigmech2418 To be clear, this is only a requirement for projects which use an absolutely huge number of assets. Which is certainly some - even beyond comp09's out-of-the-ordinary animations, the two others I noted also were huge memory hogs. But not most, and the editor is definitely usable without @as-com's noted requirements.

[AmazingMech2418]

@towerofnix Still. A lot of large projects would be completely impossible for some Scratchers to run. There are other cases very similar to this.

[as-com]

The main problem here is that Scratch 3.0's memory consumption has ballooned by a non-trivial amount for projects that have a large number of costumes. There was a recent (?) featured project that contained about a thousand SVGs (hand-drawn stop motion), so I know I'm not the only one producing projects of this type. The "Bad Apple" project that is the subject of this issue ran fine with "just" a couple gigabytes of memory in Scratch 2.0.

It appears that when Scratch 3.0 loads a costume/skin, it immediately rasterizes the SVG and saves it in memory, then copies it to video memory, which may be shared with or spillover to system memory. (I may be wrong, since I only briefly traced through the code.)

One option for optimizing memory usage is to load the costume only when it is shown on screen and toss it from memory when it is hidden, which is similar to Scratch 2.0. This can be further optimized by rendering the SVG's polygons with WebGL every frame, which has the side effect of efficiently handling size changes without blurry scaling.

[as-com]

Status update: my new MacBook Pro (meeting the above system requirements) just arrived, and it runs this project flawlessly!

Scratch-ing is about to become very, very expensive...

[hedgehog125]

How long does it take for an image to be loaded? It might make sense to only decode it and render it when it's needed if a project has significant assets? It would also have to unload some of the assets when they haven't been used for a while. Although, it might take too long. :/ How does Scratch 2.0 deal with this problem?

[towerofnix]

Here is another project, by TheLogFather, which eats up memory and crashes my computer: https://scratch.mit.edu/projects/140694370/

I'm bumping this topic because, well, it's actually very important to deal with before the release of Scratch 3.0. Once 3.0 is released, projects on Scratch will start to automatically be loaded with the 3.0 editor; that's the whole reason there is 2.0 compatibility built in. This means that users will automatically run into this problem. Their computers, or at least browsers, will automatically start crashing. Hopefully this is clearly an extremely bad and unacceptable thing.

[as-com]

Good news: Scratch 3.0 has significantly reduced its CPU and memory usage since I last tested it. Bad news: It's still really bad.

And by the time this project is done running, it's also using 6.4 GB of VRAM.

And Safari still gives up and kills the tab before the project can load.

Here's a heap snapshot from Firefox: 299524.fxsnapshot.zip

[Explosion-Scratch]

This is super interesting, I'll try this!