Discuss Scratch
- Discussion Forums
- » Questions about Scratch
- » What's the downside to running without screen refresh?
- PhirripSyrrip
- Scratcher
500+ posts
What's the downside to running without screen refresh?
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:
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 thought I'd get away from you, didn't you?!
- jvvg
- Scratcher
1000+ posts
What's the downside to running without screen refresh?
I think running a block without screen refresh means that the results of the block won't show up until it's done.
Professional web developer and lead engineer on the Scratch Wiki
Maybe the Scratch Team isn't so bad — Why the April Fools' Day forum didn't work last year
- drmcw
- Scratcher
1000+ posts
What's the downside to running without screen refresh?
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. 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:
- DadOfMrLog
- Scratcher
1000+ posts
What's the downside to running without screen refresh?
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!
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!
Last edited by DadOfMrLog (Aug. 20, 2013 20:56:44)
Alternate account: TheLogFather –– HowTos and useful custom blocks (see studio). Examples below…
- String manipulation - - - X to power of Y - - - Clone point to clone - Detect New Scratcher - Speed tests studio -
- ProdigyZeta7
- Scratcher
1000+ posts
What's the downside to running without screen refresh?
Normal speed - 1/60th of a second is the fastest a project can go tl;dr
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
Last edited by ProdigyZeta7 (Aug. 20, 2013 21:24:56)
- PhirripSyrrip
- Scratcher
500+ posts
What's the downside to running without screen refresh?
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.
when gf clicked
custom block
define custom block (run without screen refresh)
1s1s project scripts
Thanks.
; ; ; ; ; ; ; ;You thought I'd get away from you, didn't you?!
- ErnieParke
- Scratcher
1000+ posts
What's the downside to running without screen refresh?
That would still be considered 1s2s ( 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: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.
when gf clicked
custom block
define custom block (run without screen refresh)
1s1s project scripts
Thanks.
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
- DotDash
- Scratcher
1000+ posts
What's the downside to running without screen refresh?
its 2 script 1 spriteThat would still be considered 1s2s ( 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: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.
when gf clicked
custom block
define custom block (run without screen refresh)
1s1s project scripts
Thanks.
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
My browser / operating system: MacOS Macintosh X 10.8.5, Chrome 29.0.1547.76, Flash 11.8 (release 800)
- PhirripSyrrip
- Scratcher
500+ posts
What's the downside to running without screen refresh?
No, it's 1 sprite 2 scripts. And thank you ErnieParke.its 2 script 1 spriteThat would still be considered 1s2s ( 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: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.
when gf clicked
custom block
define custom block (run without screen refresh)
1s1s project scripts
Thanks.
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
; ; ; ; ; ; ; ;You thought I'd get away from you, didn't you?!
- RoboTax
- New to Scratch
8 posts
What's the downside to running without screen refresh?
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.
- Discussion Forums
- » Questions about Scratch
- » What's the downside to running without screen refresh?