I used a custom block and turned on screen refresh so everything could go smoothly, but it makes it very slow and I don't know why.

It's because it runs the blocks a lot faster than usual, and the faster they run, the laggier it gets.

You could be using a wait block in it… so, what would waiting as fast as possible do? You would end up trying to wait so much that you don't have time to do anything else. The same applies to custom blocks without screen refresh.

How much code is in this block? The screen isn't updated until the code in the block has finished* - so it follows that if the code in your custom block takes over 1/30th of a second to run, the screen won't be updated on time, resulting in reduced framerates.

Ihatr wrote:

It's because it runs the blocks a lot faster than usual, and the faster they run, the laggier it gets.

This doesn't make much sense to me.† How does it get laggier when the blocks run faster?

The blocks always run as fast as possible (or at least, I assume they do - there would be no reason not to), and the only thing restricting their speed is that when the code is done running, it waits until it's time to update the screen before the code runs again. You can remove this cap by turning on Turbo Mode, and the code will run without this limitation.

*But in my experience, this isn't always true. If the code takes more than 1 second or so to run, execution is interrupted and the screen is updated forcibly - presumably, to avoid the appearance that Scratch has frozen.

†Now that I think about it, I guess that if Scratch was very poorly written, it would be possible for too much time to be dedicated to running blocks and not enough to updating the screen or other things, resulting in the appearance of lag. But I've never observed something like this.

Hey, I just had an epiphany as to why wait blocks in custom blocks that run without screen refresh cause lag - because it must run the block before updating the screen, and if there's a wait block, it must wait for that block to finish before it updates the screen, causing massive lag. (Wow, is this post turning into a stream-of-consciousness or what?)

6dh wrote:

I used a custom block and turned on screen refresh so everything could go smoothly, but it makes it very slow and I don't know why.

Here’s how I think of it: basically, when you tell it to run without screen refresh, scratch will try and do everything in that block instantly. If there is a wait script, or a wait block that takes a while to activate, it can’t do it as instantly as it expects, and it will slow the project down massively in it’s futile efforts to speed up time. If your blocks can’t be calculated instantly, the aren’t compatible. Not a super accurate explanation but this should help you recognise and avoid this problem.

Run without screen refresh does exactly what it says on the tin: it runs scripts before it refreshes the screen. However, if you have some sort of forever or repeat until loop then Scratch still has to execute code before the screen changes. Logically if Scratch is unable to run the code any faster it's forced to lower the screen refresh rate in order to comply. As Flowermanvista said Scratch forces these blocks to update at least once a second so Scratch doesn't fully crash.

Flowermanvista wrote:

†Now that I think about it, I guess that if Scratch was very poorly written, it would be possible for too much time to be dedicated to running blocks and not enough to updating the screen or other things, resulting in the appearance of lag. But I've never observed something like this.

Each time Scratch reaches a yield point (a wait block, the end of a loop), it checks to see how much time it has left to run blocks. If it has less than 75% of its allocated time left, it will stop running blocks to refresh the screen.

Flowermanvista wrote:

Hey, I just had an epiphany as to why wait blocks in custom blocks that run without screen refresh cause lag - because it must run the block before updating the screen, and if there's a wait block, it must wait for that block to finish before it updates the screen, causing massive lag. (Wow, is this post turning into a stream-of-consciousness or what?)

It actually has to wait for the screen to refresh before the custom block will run again. When the custom block runs again, it will check if it has finished waiting. Since the screen refresh is disabled, that won't happen for 0.5 seconds when Scratch forces one. You can see this since these two blocks create the same amount of lag (watch the timer update on the screen).

Edit: Rereading this I was kind of skeptical about that second part, but modifying the test you can see it is true:

define lag1
change [variable v] by (1) // Only changes once per 0.5 secs
wait (0.1) secs

reset timer
forever
lag1
end

define lag2
forever

end

reset timer
lag2

Thanks, this helped a lot. For anyone else still wondering why wait blocks cause a large amount of lag in custom blocks set to ‘run without screen refresh’ enabled, or why the screen still refreshes as if the block is set to ‘run without screen refresh’ disabled, I’ll try my best to summarise. Let me know if any of this information is incorrect.

As Flowermanvista explains:

If the code takes more than 1 second or so to run, execution is interrupted and the screen is updated forcibly - presumably, to avoid the appearance that Scratch has frozen

That is a custom block with ‘run without screen refresh’ enabled has a maximum time of about one second, in which it needs to execute the blocks inside this custom block. If it fails to fit within this time limit, Scratch will force a screen refresh, most likely so as to make sure Scratch does not appear to have frozen or crashed. To further elaborate, imfh mentions that this forced screen refresh happens at certain points, for example at the end of a loop or at a wait block. It then calculates the amount of time left to finish executing the blocks inside the custom block, and if it has less than 75% (about 0.75 seconds) left of the allocated time to execute the blocks, Scratch will then stop running these blocks to force a screen refresh, which will take about 0.5 seconds to do this before running the custom block again according to imfh.

In terms of lag, having a wait block or never ending loop inside a custom block with ‘run without screen refresh’ enabled will cause lots of lag, as Scratch is stopping for this wait block or never ending loop and waiting for it to finish. D-ScratchNinja summarises this perfectly:

You could be using a wait block in it… so, what would waiting as fast as possible do? You would end up trying to wait so much that you don't have time to do anything else. The same applies to custom blocks without screen refresh

Tutor-42 explains this in a topic, and calls them ‘yield points’ - that is the order in which scripts are run in Scratch, and when Scratch pauses a script to run other scripts in a project. Tutor-42 explains in one of the posts in the topic, that the yield points in Scratch are:

- The end of any loop, ie. the end of any Repeat, Repeat until, or Forever loop.
The script yields each time the blocks inside the loop have been executed.

- Any type of wait ie. wait secs, wait until

- Other blocks where the script waits until the action is complete before executing the next line
eg. broadcast and wait, play sound until done, glide … secs to, say/think … for secs

- End of a script
(also the stop this script block)

Therefore by putting wait blocks or never ending loops inside a custom block set to ‘run without screen refresh’ Scratch is forced to yield the custom block to run other scripts (instead of pausing the entire project for the wait block to finish) and effectively overriding the ‘run without screen refresh’. On top of this, Scratch aims to refresh the screen (without turbo mode) about 30 times a second - however, with the ‘run with screen refresh’, Scratch is not able to refresh its screen in time - consequently this results in lag and the forced screen refreshes every ~0.5 seconds.

So the bottom line is that you should try to avoid from using any wait blocks (including wait until etc.) and never ending loops inside a custom block set to ‘run without screen refresh’ enabled, otherwise this may very likely result in lag and forced screen refreshes, which can be very detrimental to your project.
Otherwise I also have a project demonstrating this. If you want to read more about the ‘yielding’ and the way Scratch executes its scripts (and some more), I’d suggest briefly reading over Tutor-42’s topic. Hopefully this helps!