Hello to everyone! I've realized, that warp block restricts FPS by 30! Is it ok?...
Here is my sample project with fps counter. Normally it runs at 60 fps (my monitor refresh rate?), but it slows to 30 fps when I use moving blocks inside WARP block. Here in this project up and right arrows are handled without WARP, and left arrow uses WARP. You can see immediate fps drop when pressing left. Is it a bug of a feature, or I'm doing something whong?
Hi! Welcome to the forum.
WARP can't actually speed up your computer; it works by giving the warped thread priority over everything else, including (especially!) refreshing the display. ("Especially" because that's generally way more time-consuming than actually running your code.) So, yeah, that's to be expected.
Thank you for the answer Brian. And for the Snap! itself - it is very inspiring! Could you please describe WARP functionality in more detail? I can't understand why the code with priority over everything else works slower than regular code. Is there any reason to use WARP at all, if it actually slows the program?
Quick demo
Loops are normally restricted to the screen refresh rate
Stick the loop inside a warp loop and that restriction is removed
Don't think faster or slower; it's a matter of setting priorities for the computer's limited resources.
Ordinarily our scheduling priority is to keep the stage display synchronized with the running scripts, and also to keep the scripts synchronized with each other, so that the animation is smooth and predictable. So a thread runs until an explicit yield point, which is usually the bottom of a loop script (the inside of a FOREVER or REPEAT, etc.), then another script runs, and so on, and then the display refresh runs. This is why you can have FOREVER [MOVE 10 STEPS] in one script and FOREVER [TURN 15 DEGREES] in another script, and you'll see a perfect circle; there's exactly one TURN for each MOVE.
Turbo mode maintains the synchronous running of scripts, but doesn't update the display in every cycle. If you're drawing a complicated fractal, for example, normal mode will let you see every step of the drawing, but will take a long time; turbo mode will run a bunch of compute cycles and then update the display, so the drawing takes less time (because the cost of one display update is, so to speak, spread out among several compute cycles.
WARP is even more extreme; it lets only this one script run until it finishes (that is, finishes the part inside the WARP) and then updates the display all at once. So you get more computation and less display maintenance.
I don't think WARP slows the program, as you put it. It slows you seeing the result of running the program, but the computation itself is quicker, not because the computer becomes faster but because you only get one display update when it's all finished. (Actually that's a slight exaggeration; if several seconds go by inside the WARP, it does run a display cycle, not really for the sake of the display but to check if you've clicked the stop button.)
I'm starting to understand. So if I put WARP block inside a FOREVER loop, there will be TWO screen refreshes on each iteration of the loop - one after WARP block and another at the bottom of the loop script? And there will be just one screen update per iteration with no WARP, and that's why I see fps drop from 60 to 30? (I'm updating the fps counter once per iteration) Am I right?
Thank you. It seems reasonable to use WARP block outside loops, not inside