Introduction

Welcome to the SPT thread! Here are (or what will be) a collection of performance tips from various Scratchers. I felt like there was not a place to read about this, and so I am making this thread to help you get the most out of Scratch.

Do remember that this is only for those who are encountering performance issues with their projects or wish to do complex projects. Following these tips may not make a difference if your project is not using Scratch's capacity.

___________________________________________________________________________________________
The Basics

Here's a few simple tips to get you started:
1. Using these blocks may cause lag or graphical glitches, however the Scratch Team are very close (if not already there) at fixing this. Therefore, you may be able to use these without any issues, but you must measure the pros and cons. Transparency is not affected.

Solution!
To make a sprite appear brighter, place that sprite on the stage where you want it. Then, you can draw a brighter version of it, and have that as a new costume. Or, for smoother effects you can place a white duplicate (a sprite that is the same shape and size, but does not need detail) on top of that original sprite and have it fade in. Do not set the transparency to lower than 60% or you will struggle to see the original sprite! To make sprites darker, simply do the same with a black sprite. You can easily change the time of day of a scene by placing an orange sprite on top, to make it the evening. Or place a purple/ black one to make it look like nighttime. You can even make it appear like the sun is shining, by having a blue gradient fade into a yellow dot, and placing it over your scene.

For other effects, you may have to animate them in programs like Photoshop, and save each frame as a separate image. Then, play through the costumes in Scratch.

___________________________________________________________________________________________
2. Keyboard input CAN lag some projects, but not others.
Solution!
Unfortunately this appears to be a flash based glitch, and does not affect all projects. The best advice is to try it in your project, and if it does lag then to get rid of keyboard input. Clicking the mouse many times in succession can also sometimes cause lag.

___________________________________________________________________________________________
3. Use “without screen refresh” on custom blocks!

This speeds up scripts by a HUGE deal! However, it may cause lag if you try to update graphics whilst in this mode. It is recommended to create a “game loop”, such as one below in order to split up the graphical updates from the code updates within the custom block.

It is recommended that the sprite which does the most work has the script, so that it's logic code can be put inside a custom block. Then, the other scripts are updated. It is important to add a “and wait”, so that you do not refresh the UpdateMainStuff script too many times, as Scratch will lag more if it spends too long without refreshing. This is because after a while, it forces itself to update the screen whilst trying to run your scripts super fast.

NOTE: The loop is not inside the custom block, as that is also something you should not do. Instead, the custom block is inside the loop. Also, never put a broadcast message or a broadcast message and wait block inside a custom block as this will cause immense lag.

___________________________________________________________________________________________

griffpatch wrote:

Another source of much lag is down to having too many entry points to forever loops. In other words having more than one “when green flag clicked, forever… Animate something.”. Often you could rearrange your scripts to have a single green flag clicked and do all your checks and animation in that single script. Having lots of loops can cause extra delays that you didn't expect.

___________________________________________________________________________________________
Advanced Optimization

Let's look at what griffpatch has to say-

griffpatch wrote:

One of the biggest performance gains to be had is simply trying to avoid changing costumes, size or rotation on too many spirits each frame. Of you instead can rely on moving the spirits around to give them life and switch costume perhaps every three frames instead then things can work a lot more smoothly! This only applies though if you have lots of things on screen at once .

___________________________________________________________________________________________

griffpatch wrote:

I done a bit of benchmarking and now I know that switching costumes does indeed invalidate the bitmap caching… I also found out that switching the costume to the same costume a sprite was already wearing also invalidates it and causes the program to run slower… (Note to self - compare costume# to the one I want to set it to before actually doing it… or not). I also note it might therefore be more efficient to create clones of a sprite with different frames of an animation and hide and show them to animate it?

Let me explain what he is talking about and how it can help you:
In flash player, which is what runs your project, your costumes need to be loaded and drawn onto the screen. In advanced programs, an image can be loaded once (referred to by griffpatch as bitmap caching). Once stored into memory, it is accessible far faster the next time you use that image because the image does not have to be reloaded. However, in Scratch this is not the case. Every time an image is loaded, even if you make a sprite change into the costume it is currently showing, the image in memory is wiped and replaced. The advantage of this is that it uses less memory, which is better for low end systems. However, with the recent release of browsers like 64-bit Chrome (64-bit basically means more memory can be used), it is a huge disadvantage as images could create far less lag (if any) when preloaded.

Griffpatch suggests creating clones of the same sprite, and having them appear/disappear when you do and do not need them to avoid changing the costume. He also suggests checking in advance what the costume is of the sprite before changing it, using an if statement. This means that costumes only change if they really have to.

You can do other things, such as relying on moving images rather than costumes for animation. For example, instead of drawing a person walk in 6 frames per second, why not split up the person into the different body parts and have the legs move without changing costumes? This is a harder way to do it, but it should also end up in much smoother animations because it is not limited to the number of frames that you draw.

Nice idea but I'm not sure whether it's a good idea! Performance tuning is really only required if performance is an issue. I'd worry that people would read this and then avoid using the effects blocks. Scratch is still changing and consequently so are ways of doing things, so a laggy project today might be fine tomorrow and vice versa.
I'm afraid part 3 as you've written it is incorrect on quite a few counts and dangerously so in its recommendation. Never add an “and wait” block to a custom block that is set to run without screen refresh.

drmcw wrote:

Nice idea but I'm not sure whether it's a good idea! Performance tuning is really only required if performance is an issue. I'd worry that people would read this and then avoid using the effects blocks. Scratch is still changing and consequently so are ways of doing things, so a laggy project today might be fine tomorrow and vice versa.
I'm afraid part 3 as you've written it is incorrect on quite a few counts and dangerously so in its recommendation. Never add an “and wait” block to a custom block that is set to run without screen refresh.

What I've written is actually correct, but I've updated it to avoid confusion.

You thought I meant was that the broadcast message is inside the custom block. This is not true, the loop contains a custom block, followed by a broadcast message that is ran before the custom block is repeated. Also, I've added that these tips will not help if your project isn't already lagging, and I've also added that the effects glitch is being worked on, but it does not work perfectly at the moment.

Hey there, just wanted to add an update here since there have been updates to scratch since I wrote some of the things you mention here. Firstly, it is no longer costly to use the brightness effects block (so you can now use brightness and ghost effects without any performance issues). Secondly, I might be wrong, but it's possible scratch has been updated to remove the issue with costume changes where you change to the same costume you were already using causing a delay… But I'd need to check really

One of the biggest performance gains to be had is simply trying to avoid changing costumes, size or rotation on too many spirits each frame. Of you instead can rely on moving the spirits around to give them life and switch costume perhaps every free frames instead then things can work a lot more smoothly! This only applies though of you have lots of things on screen at once .

Another source of much lag is down to having too many entry points to forever loops. In other words having more than one “when green flag clicked, forever… Animate something.”. Often you could rearrange your scripts to have a single green flag clicked and do all your checks and animation in that single script. Having lots of loops can cause extra delays that you didn't expect.

griffpatch wrote:

Hey there, just wanted to add an update here since there have been updates to scratch since I wrote some of the things you mention here. Firstly, it is no longer costly to use the brightness effects block (so you can now use brightness and ghost effects without any performance issues). Secondly, I might be wrong, but it's possible scratch has been updated to remove the issue with costume changes where you change to the same costume you were already using causing a delay… But I'd need to check really

Thankyou for your input! I will update the information about the effects blocks. I will update the costume change section once someone has tested this out and proven that it has been fixed.

griffpatch wrote:

One of the biggest performance gains to be had is simply trying to avoid changing costumes, size or rotation on too many spirits each frame. Of you instead can rely on moving the spirits around to give them life and switch costume perhaps every three frames instead then things can work a lot more smoothly! This only applies though if you have lots of things on screen at once .

I will also add this quotation to the thread!

griffpatch wrote:

Another source of much lag is down to having too many entry points to forever loops. In other words having more than one “when green flag clicked, forever… Animate something.”. Often you could rearrange your scripts to have a single green flag clicked and do all your checks and animation in that single script. Having lots of loops can cause extra delays that you didn't expect.

And another great example! Thankyou for helping to make this a more useful thread to Scratchers with lagging projects.