This is a great suggestion.

Although there have been some improvements to 3.0s project management, (it was unusable on most browsers after it's initial launch before updates were made and I'm thankful for those improvements) I still think there is much more improvement to be made. I think the Scratch Team should consider taking ideas from their community made scratch mods like Turbowarp that have numerous improvements. While many of Turbowarp's features are deliberately not added to scratch, things like memory management can definitely be implemented (at least in theory)

Walle10-0 wrote:

This is a great suggestion.

Although there have been some improvements to 3.0s project management, (it was unusable on most browsers after it's initial launch before updates were made and I'm thankful for those improvements) I still think there is much more improvement to be made. I think the Scratch Team should consider taking ideas from their community made scratch mods like Turbowarp that have numerous improvements. While many of Turbowarp's features are deliberately not added to scratch, things like memory management can definitely be implemented (at least in theory)

Turbowarp's memory management isn't better than Scratch's.

dhuls wrote:

Walle10-0 wrote:

This is a great suggestion.

Although there have been some improvements to 3.0s project management, (it was unusable on most browsers after it's initial launch before updates were made and I'm thankful for those improvements) I still think there is much more improvement to be made. I think the Scratch Team should consider taking ideas from their community made scratch mods like Turbowarp that have numerous improvements. While many of Turbowarp's features are deliberately not added to scratch, things like memory management can definitely be implemented (at least in theory)

Turbowarp's memory management isn't better than Scratch's.

they're talking in general terms, i believe. at least for that part.

I've always noticed the off-line editor is better at running projects, because it's an app… I had an idea. What if there was a downloadable version of the scratch website, that would load project assets differently? That seems like a suggestion that would fix this feature, but doesn't necessarily fit under this topic.

ScolderCreations wrote:

I've always noticed the off-line editor is better at running projects, because it's an app… I had an idea. What if there was a downloadable version of the scratch website, that would load project assets differently? That seems like a suggestion that would fix this feature, but doesn't necessarily fit under this topic.

https://desktop.turbowarp.org/ (Click on the Chrome tab.)

I have an idea.

Scratch should have a new extension called RAM Management. It would be able to control how much ram is used. Before we introduce the blocks, let's talk a little about the quirks.

• Loading is loading the specified costume or sound into RAM.
  

• Unloading is removing the specified costume or sound from RAM.
  

• Fully unloading a sprite isn't possible.
  

• Unloading will never unload any costume that is in use (the sprite is currently using).
  

• Unloading a sound will stop that specific sound playing before it is unloaded.
  

• Switching to a unloaded costume or playing a unloaded sound will first load the asset. The asset will never unload unless it is told to.
  

• Backdrops are costumes too.
  

Finally, let's introduce the first block. Remember that the exceptions and quirks always apply.

when flag clicked
unload all

This block unloads all costumes and sounds. BeforeI loading, Scratch would check if a green flag clicked block has an unload all block in it's script like the above example. This check would happen after the code loads but BEFORE the assets load. This will result in quicker load times and less RAM usage. However, each sprites current costume and the current backdrop still get loaded when the project loads but AFTER the check. If this script is not in a project, the project will load how it does now.

load sound [meow v]
load costume [bird v]
load backdrop [Blue Sky v]

These blocks load the specified sound or costume. They can be used to load an asset prior to using it. This removes the delay from if you were just to play the sound or switch to a costume. Loading an asset into RAM takes time and this is a way to mitigate it. There is an “all” option too, which basically loads all sounds or costumes in the sprite (or backdrop).

unload sound [meow v]
unload costume [bird v]
unload backdrop [Blue Sky v]

Basically the load asset blocks except they unload the specified asset. You can use this to save RAM by unloading what you don't need. The all option exists for these blocks too.

load all

Probably the most pointless block, this block loads ALL costumes and sounds for every sprite (Backdrop included). The only use case I could think of this if you want to ensure everything is loaded. Basically forces a Scratch Project to load how it does now.


I'm getting kind of tired of writing this post so I hope this gets added because it would be awesome for advanced scratchers with big files.

when green flag clicked
Follow [CoderQC]
stop [this script v]

CoderQC wrote:

-big snip-

That looks like a good idea to me, but I think it'd be better as its own suggestion.

CoderQC wrote:

Scratch should have a new extension called RAM Management. It would be able to control how much ram is used. Before we introduce the blocks, let's talk a little about the quirks.

So, lets say that a costume is loaded, and now needs to be unloaded, it's removed from memory. But if we need to load it again - it's going to ask the server for it - this is going to make a LOT of network calls, even though memory usage is less. Loading and unloading essentially means asking the server to send an asset, and deleting what the server has sent, respectively.

unloading and loading costumes as in your examples all the time will likely make performance worse, since it needs to re-fetch the assets from either a local cache or the server each time.

potatophant wrote:

local cache

Actually can you store pngs/svgs/audio files in localStorage?
Fetching it from the server is pointless and is only going to make matters worse, for a person with slow internet and the scratch asset server


— https://stackoverflow.com/questions/43816266/saving-audio-to-localstorage-for-playback

potatophant wrote:

unloading and loading costumes as in your examples all the time will likely make performance worse, since it needs to re-fetch the assets from either a local cache or the server each time.

That's why I made the load block. You can load in a costume prior to displaying. You would use this block in like, a loading screen.

Also, localStorage has a 5 MB limit and we're trying to reduce RAM here. Unless localStorage is disk, then that might work.

I made this optional too. Remember?

when green flag clicked
Follow [CoderQC]
stop [this script v]

I just realized the example was the WRONG way to use it!



The right way would be to first have a loading screen to load a quarter of the whole gif. This example is a game with a long intro cutscene after all.
When the loading screen goes away, the first quarter would play while the second quarter gets loaded in the background.
While the second quarter is playing, the third quarter is getting loaded and the first quarter is getting unloaded.
The same goes for the third quarter, except the fourth quarter is getting loaded and the second quarter is unloaded.
Finally, after the fourth quarter is loaded, the third quarter is unloaded. You can either use this time to quietly load the main menu or have a loading screen after that to do the same task.

New Scratchers can easily abuse this to create network spam or basically a DDOS attack. I wouldn't make it available for New Scratchers.

The reason why I wanted if you switch to a costume or play a sound that is not loaded, Scratch would first halt the project and load it, then unhalt it and show the new costume or play the sound, is because of simplicity reasons for Scratchers not that advanced.

when green flag clicked
Follow [CoderQC]
stop [this script v]

I use a 2019 iMac for most of my programming. It's annoying having a pop-up telling me that Scratch is using more RAM then some of my other apps, like Minecraft! That's ridiculous!

Chiroyce wrote:

potatophant wrote:

local cache

Actually can you store pngs/svgs/audio files in localStorage?
Fetching it from the server is pointless and is only going to make matters worse, for a person with slow internet and the scratch asset server


— https://stackoverflow.com/questions/43816266/saving-audio-to-localstorage-for-playback

but loading from disk is slow, which is my point.

If you're complaining about Network Spam, doesn't Scratch already spam the asset servers when trying to load a project? If a project has 803 assets, then the project will send 803+ requests to the server.

when green flag clicked
Follow [CoderQC]
stop [this script v]

CoderQC wrote:

If you're complaining about Network Spam

Read the title - I'm talking about heavy memory usage on the client's machine. After the assets are loaded, they take up a TON of space in memory.

support as scratch as it is now often crash devices , even with the limit

Chiroyce wrote:

CoderQC wrote:

If you're complaining about Network Spam

Read the title - I'm talking about heavy memory usage on the client's machine. After the assets are loaded, they take up a TON of space in memory.

I know, I made blocks to control RAM usage. You might remember them but if you don't, scroll up.

This would be limited to Scratchers since it's easy to abuse.

when green flag clicked
Follow [CoderQC]
stop [this script v]

CoderQC wrote:

This would be limited to Scratchers since it's easy to abuse.

The blocks seem pointless, if you have a long animation you'd have to spend a long time using load blocks to load it in - so most people would avoid using it since it's a waste of time. And even if it gets added, there's no use since a lot of the most memory intensive projects' creators no longer use scratch. It can be used in the future, but it's just over complicating things. We'd have to sacrifice performance for memory, so if you have an animation that needs 30 FPS, it'll barely get around 15 since fetching assets will take a lot of time, and unloading them also will.

bump