OK, so running a custom block without screen refresh makes sure that you don't get the tiny lag that makes the “wait 1 sec” block wait a little over 1 sec, is that right?

What I want to know is, is there any negative aspect of using it? Because it sound too good to be true, and if it really works, then why isn't the default setting to run without screen refresh? Surely that would make projects better, especially ones that require precision timing (I'm working on a lyric video on Scratch right now, and this looks like it would be useful.)

So have I got my understanding of running without screen refresh right, and would there be any problems in using it too much? And why isn't it the default setting, if there are no problems and my understanding of it is correct?

I've only used run without screen refresh once, in a project where I used repeated stamping to display the player's score.

Thanks :cook:

I think running a block without screen refresh means that the results of the block won't show up until it's done.

PhirripSyrrip wrote:

OK, so running a custom block without screen refresh makes sure that you don't get the tiny lag that makes the “wait 1 sec” block wait a little over 1 sec, is that right?

What I want to know is, is there any negative aspect of using it? Because it sound too good to be true, and if it really works, then why isn't the default setting to run without screen refresh? Surely that would make projects better, especially ones that require precision timing (I'm working on a lyric video on Scratch right now, and this looks like it would be useful.)

So have I got my understanding of running without screen refresh right, and would there be any problems in using it too much? And why isn't it the default setting, if there are no problems and my understanding of it is correct?

I've only used run without screen refresh once, in a project where I used repeated stamping to display the player's score.

Thanks :cook:

You want the block to run as quickly as possible. If you put a delay in there like wait then you'll cause no end of pain for your project. So be carefull! How I see it is that you're telling Scratch that your block runs quickly so it will run it and run nothing else until it is complete (hence the speed). If it doesn't run quickly because you've stuck a wait in there then the rest of your project won't be running and so you get lag and lots of it.

Yeah, drmcw is spot on - while Scratch is executing a non-refresh block, nothing else gets run until it finishes. (Caveat: there's about a half second limit before it does allow other things to happen.)

This means if you have anything in there that waits for something else to happen (e.g. “wait until”, “broadcast and wait”), it'll be waiting forever! (ok, ok, it'll be waiting for half a second - but that's near enough forever if you're doing it every time through your project's main loop… )

The ‘non-refresh’ part means that Scratch doesn't make any updates to what's shown on the screen while that block is running. This is different to normal running, where a change to the looks of a sprite (and a few other things) will cause Scratch to change what's shown on the screen (hence slowing down everything).

It's also different to “Turbo Mode” - in fact, it's actually faster, because even turbo mode does do various updates to the screen at regular intervals.

However, it's also worth noting that a script which doesn't make changes to the look of things on the screen will actually run almost as quickly as in non-refresh mode, so it doesn't necessarily need refresh disabling. And having lots of things being done in non-refresh can cause some keypress-related lag problems for some people, due to Scratch needing time to deal with keyboard (and mouse) events (-if these events don't get time to be processed, some versions of Flash cause some browsers to start to freeze up…)

Hope that's useful info!

DadOfMrLog wrote:

tl;dr

Normal speed - 1/60th of a second is the fastest a project can go
Turbo speed - up to 1/3000th of a second per iteration of the code (50x faster)
No Refresh - absolute limit of your computer's flops per second. Can lag if:
1. a loop never ends
2. wait until
3. more calculations needed than half of your computers flops per second
4. key pressed
5. other code is running

Thanks everyone! Really helpful. So if I've understood correctly, I shouldn't use blocks such as “wait until” and “key pressed” as that can delay the entire project? What if it's a 1s1s project, or only one sprite is running at a time, would it be fine to use:

when gf clicked
custom block

define custom block (run without screen refresh)
1s1s project scripts

Thanks.

PhirripSyrrip wrote:

Thanks everyone! Really helpful. So if I've understood correctly, I shouldn't use blocks such as “wait until” and “key pressed” as that can delay the entire project? What if it's a 1s1s project, or only one sprite is running at a time, would it be fine to use:

when gf clicked
custom block

define custom block (run without screen refresh)
1s1s project scripts

Thanks.

That would still be considered 1s2s (or is it 2s1s? I always get the order mixed up…). Anyway, the point is if you want to make a 1s1s project, you can't use custom blocks, which can really limit some things. At least turbo can help a bit, but not in all cases.

And yes, the “Wait until <>” and other blocks with wait will delay the entire project for forever, till your browser crashes, or till your mind explodes. So don't use them (esp. if you value your mind).

With regards,

ErnieParke

ErnieParke wrote:

PhirripSyrrip wrote:

Thanks everyone! Really helpful. So if I've understood correctly, I shouldn't use blocks such as “wait until” and “key pressed” as that can delay the entire project? What if it's a 1s1s project, or only one sprite is running at a time, would it be fine to use:

when gf clicked
custom block

define custom block (run without screen refresh)
1s1s project scripts

Thanks.

That would still be considered 1s2s (or is it 2s1s? I always get the order mixed up…). Anyway, the point is if you want to make a 1s1s project, you can't use custom blocks, which can really limit some things. At least turbo can help a bit, but not in all cases.

And yes, the “Wait until <>” and other blocks with wait will delay the entire project for forever, till your browser crashes, or till your mind explodes. So don't use them (esp. if you value your mind).

With regards,

ErnieParke

its 2 script 1 sprite

DotDash wrote:

ErnieParke wrote:

PhirripSyrrip wrote:

Thanks everyone! Really helpful. So if I've understood correctly, I shouldn't use blocks such as “wait until” and “key pressed” as that can delay the entire project? What if it's a 1s1s project, or only one sprite is running at a time, would it be fine to use:

when gf clicked
custom block

define custom block (run without screen refresh)
1s1s project scripts

Thanks.

That would still be considered 1s2s (or is it 2s1s? I always get the order mixed up…). Anyway, the point is if you want to make a 1s1s project, you can't use custom blocks, which can really limit some things. At least turbo can help a bit, but not in all cases.

And yes, the “Wait until <>” and other blocks with wait will delay the entire project for forever, till your browser crashes, or till your mind explodes. So don't use them (esp. if you value your mind).

With regards,

ErnieParke

its 2 script 1 sprite

No, it's 1 sprite 2 scripts. And thank you ErnieParke.

This was really helpful. I would like to correct one thing. Selecting no refresh in a script that does only calculations can greatly speed it up. I found this out in my symmetric pens project. The repeat not only affects screen refresh but it also yields to other scripts. If you have other scripts with repeats that do a screen refresh the time it takes the script performing the calculations may increase dramatically. Setting no refresh in my script that did the calculations sped the entire project up by a factor of 5 to 10.