Single Frame Wiki:

Scratch loop blocks are programmed with a slight delay between repetitions and thus actions are performed slowly. If this delay did not exist, simple motion scripts could cause a sprite to fly or even disappear off the screen instantly. The repeat blocks (and forever), the wait blocks, all motion blocks, the glide block, and the broadcast blocks have this delay. During this delay, an additional screen refresh is done: Scratch redraws the entire Stage. This is also a big source of lag.

Functions the same as…

…which means motion blocks do not have screen refresh. So why does it say all motion blocks (bold in quote) have screen refresh?

(Updated to reflect an accurate answer, see TheLogFather's explanation)

will look noticeably different from

I don't see a difference. I see the sprite go from (0,0) to (100,0) without any delay for both instances. Am I supposed to see a flickering or something?

I was expecting to actually see the movement like I would if I ran:

Maybe I'm misunderstanding what screen refresh does? I thought it pauses the program to refresh the screen and that's why I should see the sprite “moving” to its destination instead of just “flying” there.

bump

The refresh time is 1/30th of a second. If you want to see a difference, then do this…

and compare that to this…

I know that repeat blocks have screen refresh between each iteration, that's not what I'm asking. It says that motion blocks have this too (without using loops).

Are you saying that if I wrote “move 1 steps” 300 times it would take slightly longer than “move 300 steps”?

Related, why don't I see any flickering (screen refresh) if I run the following? shouldn't there be a slight delay and screen refresh between each iteration?

jballin2 wrote:

I know that repeat blocks have screen refresh between each iteration, that's not what I'm asking. It says that motion blocks have this too (without using loops).

Related, why don't I see any flickering (screen refresh) if I run the following? shouldn't there be a slight delay and screen refresh between each iteration?

Screen refresh does not cause any flicker. It just means that the screen has been updated. It happens 30 times a second no matter what you do.

jballin2 wrote:

Are you saying that if I wrote “move 1 steps” 300 times it would take slightly longer than “move 300 steps”?

No, I am saying if you put it in a repeat 300 times loop it will be a LOT longer. Try it yourself.

Why is it longer?

Because looping 300 times takes 10 seconds, but moving 300 steps one time takes 1/30th of a second.

Motion blocks cause screen refresh because they cause sprites to move then requring the screen update to show the sprite moved.

jballin2 wrote:

I know that repeat blocks have screen refresh between each iteration, that's not what I'm asking. It says that motion blocks have this too (without using loops).

Are you saying that if I wrote “move 1 steps” 300 times it would take slightly longer than “move 300 steps”?

Related, why don't I see any flickering (screen refresh) if I run the following? shouldn't there be a slight delay and screen refresh between each iteration?

You are not thinking deeply enough about this stuff. The script you wrote with all the nested forever loops is equivalent to one forever loop. Can you see why?

Really appreciate your help guys!!

@footsocktoe makes sense that it would take a lot longer to write 300 move 1's vs move 300

@footsocktoe you're right that once it reaches the move block it will stay in that last loop. I wrote another script using repeat blocks instead of forever blocks but still see no flickering but I realized I was confused by the example given on the single frame wiki which sets the sprite's x to 100 and then forever sets x to -x. (causes flickering if not don't change x to -x and back within same iteration)

@awesome-llama that makes perfect sense that the screen has to refresh to show any movement.
@footsocktoe, interesting that you say it happens every 1/30 seconds even though it specifically spells out motion blocks as causing screen refresh but I suppose it causes an “ADDITIONAL screen refresh” on top of the ones that already happen?

jballin2 wrote:

@footsocktoe, interesting that you say it happens every 1/30 seconds even though it specifically spells out motion blocks as causing screen refresh but I suppose it causes an “ADDITIONAL screen refresh” on top of the ones that already happen?

No. Remember that the WIKI is written by users like you and I, so maybe he just expressed the idea clumsily.

Here is the way it works. 30 times a second Scratch “refreshes” or updates the screen. Think of it as animation frames if you like.

Some blocks change the screen and some don't. For example, a broadcast block does not directly affect the screen. A play sound block does not directly affect the screen.

But blocks like move and direction and size blocks do affect the screen. If something moves, then the screen looks different when it does.

But there is no additional screen refresh, there is just the normal screen refresh. And when a project “lags” it means Scratch has so much to do that it cannot keep refreshing at 30 times a second and so it has to slow down to maybe 10 times a second or even 2 times a second.

I think I can probably help explain exactly how it works…

The way it is written on the wiki is slightly misleading – Scratch *does not* have any delay between the blocks (unless they explicitly have the word “wait” in there, such as “broadcast … and wait”, “ask … and wait”, “wait N secs”, etc).


However, the way that Scratch shares time between currently running scripts is to spend time exclusively executing each one up to its next “yield point”. This includes things like a wait block (such as those above), the end of a script, or the end of a loop (unless it's running as a non-refresh custom block script).

Once Scratch reaches a yield point for a script, it ‘parks’ execution of that script and moves on to the next running script.

Once it has done a pass through all currently running scripts (so they have all reached yield points), Scratch will then commit all pending pen strokes to the pen canvas and perform a screen refresh – *unless* it is in turbo mode, or it did not come across any blocks that could potentially cause something on-screen to change (e.g. a motion block, or looks block, or pen down, etc.)

The screen refresh only happens 30x per second, so there will be a ‘pause’, since Scratch will not start to work its way through the currently-running scripts again until that refresh has finished.


This all means that if you have 300 “move 1 step” blocks, all joined to each other in a single long script, it will behave just the same as a single “move 300 steps” block. (Except that it'll take more CPU effort for it to execute all of those blocks – but as long as your computer is fast enough to do it within 1/30th second then it'll look no different. If it can't manage to execute those 300 move blocks within 1/30th sec, and it's continually trying to do them over and over, then the frame-rate will drops to <30fps.)


What the wiki is referring to, then (not very well, unfortunately), is that any motion block(s) getting executed anywhere in a script (since the last refresh) will cause a refresh to happen (and hence a delay) after all scripts reach their yield points (assuming not in turbo mode).

However, all motion blocks executed up to those yield points (in all scripts) will be ‘lumped together’ in the same refresh.


If turbo mode is on then the behaviour changes somewhat – Scratch will (mostly) forget about doing any screen refresh, and simple go back to continue executing the scripts up to their yield points. Scratch will only do the refresh once it has been nearly 1/30th second since the last refresh.


Hope that makes sense!

1. Does screen refresh have to happen on schedule?

Meaning that it can only happen at 1/30 seconds, 2/30 seconds,…n/30 seconds (where n is any positive integer)?

2. Is my understanding below correct?

A “yield point” is when a script ends, a loop ends, or a wait block is called. Scratch waits until all scripts have reached their yield point before resuming. If there is no screen refresh, the scripts will run as fast as they can but each one will have to wait for the rest of the scripts to reach a yield point of some kind before resuming.

If the screen needs to be refreshed, Scratch will wait wait 1/30 seconds and meanwhile evaluate each script to its next yield point. The screen will then refresh to display any visual changes, allowing beginners to visualize the program's progress. Then the program resumes.

Screen refresh only happens if one (or more) of the scripts prior to their respective yield points contains a motion block, a looks block, a certain sound block (change/set tempo/volume), or a pen block. Otherwise it will run as fast as its slowest script.

If a screen refresh is imminent and the slowest script can't reach its yield point in less than 1/30 seconds, the program will “lag” as it waits until the next x/30 seconds where the slowest script has finished running (complex scripts, such as 3D rendering, can take a long time). This will result in the screen refreshes having more than 1/30 seconds in between each one (effectively <30 frames per second).

3. Why don't these run in equal time when run in the same program?

speed: n/30 * 1/2 = n/60

speed: n/1 seconds + (some change) = n

Why doesn't the empty repeat block wait for the other repeat block to reach a yield point? 2nd loop first reaches the wait block which is a yield point so 1st loop goes to the next iteration, should it not wait 1 second until moving to the next because that is when loop 2 will reach its yield point (end of loop)? Note that loop 1 does have some refresh given that it is a factor of 1/30, but there isn't even anything here that should cause the screen to refresh?

4. Why does the wiki mention the broadcast block as a cause of screen refresh?

My tests didn't reveal that. Obviously if the broadcast had a motion block it will cause screen refresh, but without it it would not.

Scratch updates the screen 30 times a second even if the project contains no blocks at all. Nothing in the project “causes” this update. It's just the way computers and monitors work.

Scratch tries to run all the scripts it is supposed to run between screen refreshes. If it can, then refresh and update are the same thing. If it cannot, then there can be an update with no refresh. In other words, the image is frozen on the screen. We call it lag.

As far as an empty repeat n vs. a repeat n with wait 1 sec in it… the first one can run to completion in less than 1/30th of a second. The second one takes n seconds before it's finally done. During each of those seconds the screen will update 30 times.

footsocktoe wrote:

Scratch updates the screen 30 times a second even if the project contains no blocks at all. Nothing in the project “causes” this update. It's just the way computers and monitors work.

No, Scratch itself does not allow Flash to perform a screen update if it is blocking due to some other execution.

The frequency of the display monitor itself (which would typically be way faster than 30Hz these days, but I think that's what you have in mind?) is totally unrelated to Scratch or Flash, and is essentially irrelevant here.

jballin2 wrote:

1. Does screen refresh have to happen on schedule?
Meaning that it can only happen at 1/30 seconds, 2/30 seconds,…n/30 seconds (where n is any positive integer)?

An interesting question…

I would suspect the answer is no – if a refresh gets delayed, then Flash will probably do it as soon as it is able, without waiting for the next 1/30th second ‘slot’. (Could be wrong about that, though – you would have to read up more specifically on how Flash works, since it's really nothing to do with Scratch.)

jballin2 wrote:

Why doesn't the empty repeat block wait for the other repeat block to reach a yield point?

The simplest way to think of the wait block is that it is like an ‘internal’ repeat until loop – it is *continually* yielding to the other script(s) until that 1 second limit is reached (at which point it hits the end of the loop and yields again…)

jballin2 wrote:

4. Why does the wiki mention the broadcast block as a cause of screen refresh?

Can you point to where it says this? –I'd be interested in seeing the context…

For a normal broadcast block there's no delay at all. Scratch simply appends all the receiver scripts for that broadcast to the list of currently running scripts (apart from any which are already in the list, which have their execution point reset to start), and then moves straight on to the next block after the broadcast. The receiver scripts that got added to the execution list only get chance to start up after all other running scripts, that were already in the list, have yielded (but *before* the next refresh).

However, if it is a “broadcast and wait”, and If at least one of the receiver script(s) contains a block that causes a potential on-screen change (e.g. motion, looks, etc.) then the “wait” essentially means that it will only start executing the subsequent block (after the broadcast and wait) once the refresh has happened. –It's possible whoever was writing on the wiki page had this in mind…?



Going back to your original post, it's probably worth noting that the “single frame” wiki page looks to me as though it is related to the “all at once” C block, which does not exist in Scratch 2. (It was in an early alpha, IIRC, but was removed way before more general release, to be superseded by the “run without screen refresh” for custom blocks.) It's not really relevant to Scratch today, so best to ignore that page.

1. Interesting that wait blocks are like continuous yield points!

2. Broadcasts on Single Frame Wiki:

Scratch loop blocks are programmed with a slight delay between repetitions and thus actions are performed slowly. If this delay did not exist, simple motion scripts could cause a sprite to fly or even disappear off the screen instantly. The repeat blocks (and forever), the wait blocks, all motion blocks, the glide block, and the broadcast blocks have this delay. During this delay, an additional screen refresh is done: Scratch redraws the entire Stage. This is also a big source of lag.

3. Is my understanding correct?

jballin2 wrote:

A “yield point” is when a script ends, a loop ends, or a wait block is called. Scratch waits until all scripts have reached their yield point before resuming. If there is no screen refresh, the scripts will run as fast as they can but each one will have to wait for the rest of the scripts to reach a yield point of some kind before resuming.

If the screen needs to be refreshed, Scratch will wait wait 1/30 seconds and meanwhile evaluate each script to its next yield point. The screen will then refresh to display any visual changes, allowing beginners to visualize the program's progress. Then the program resumes.

Screen refresh only happens if one (or more) of the scripts prior to their respective yield points contains a motion block, a looks block, a certain sound block (change/set tempo/volume), or a pen block. Otherwise it will run as fast as its slowest script.

If a screen refresh is imminent and the slowest script can't reach its yield point in less than 1/30 seconds, the program will “lag” as it waits until the next x/30 seconds where the slowest script has finished running (complex scripts, such as 3D rendering, can take a long time). This will result in the screen refreshes having more than 1/30 seconds in between each one (effectively <30 frames per second).

Edit to 1st paragraph with new wait block info:

A “yield point” is when a script ends, a loop ends, or a wait block (will continually yield to other scripts until complete) is called. Scratch waits until all scripts have reached their yield point before resuming. If there is no screen refresh, the scripts will run as fast as they can but each one will have to wait for the rest of the scripts to reach a yield point of some kind before resuming.