Run Without Screen Refresh

Is there a way to write blocks that run without a screen refresh in Snap!?

I've seen the warp function, but it doesn't seem to work really well.
Perhaps it would help to say that I'm trying not to slow down my code.
WASD keys:

.you can turn turbo mode on, use this block untitled script pic (2)

just wait until the next update, the warp function is your best bet.

Hi, welcome to the forum!

WARP is your best bet; I'm surprised it doesn't work for you. It gives that thread the entire time that Snap! has to offer, except that once every few seconds (eternity for a computer) it checks to make sure you haven't clicked the stop button. If your script isn't fast enough, then either it's just inherently slow or else you have a lot of browser tabs open, so Snap! itself isn't getting much processing time.

warp

With "prefer smooth animation" this almost empty script took 4 s to complete and slows down with every NOT nested warp.
Basic repeat + warp now works @ 15FPS, by design.

That's because you're doing something wrong.
It shouldn't be
untitled script pic (11)
it should be
untitled script pic (12)
with the warp block outside the repeat block.

I'm afraid You missed the point.
Using "warp" inside loop slow down animation to 15 FPS. Many consecutive "warp" slows down to a crawl - regardless of amount of calculation done.

@bh
Does the warp function run at 15 FPS? If so, that could be my problem. I'm trying to run a faster animation.

I tried the scripts and the faster one is with the warp block outside the loop

oh and I'm on mobile

I had a similar discussion here: Expert Snappers who know how to make things faster?. It gets advanced towards the end but it explains how WARP works with FPS.

I'll take @dardoro's word for it, although "Prefer smooth animation" also slows down the display. But WARP is meant for code that isn't trying to display an animation; it's for code that's doing a lot of computation rather than a lot of displaying. So for example we just had a thread about finding the difference between two pictures, and it goes through all the pixels in a huge loop before it displays anything. That's where you want WARP.

There's no magic about WARP or Turbo mode. Your computer is only as fast as it is! These features take time away from displaying in order to give more time to computation. Display cycles take a lot of time; it's not just putting your pen trails on the stage, but also updating things like the sprite corral and the variable watchers (especially the ones with list view on a large list). So it's a tradeoff between time spent displaying and time spent computing.

"prefer smooth animation" has been deprecated since we've switched over to requestAnimationFrame().

Yeah, that too. :~)

@jens What are "prefer smooth animation" and requestAnimationFrame()?

"prefer smooth animations" was a setting where we limited the frame rate to 30 fps, it's been deprecated now that we're using the "official" HTML5 animation frame API that runs at around 67 fps.

Yes "smooth animation" is now disabled by default, but projects store it as "Stage.scheduled" attribute.

The real problem is "warp" block that yields at the end.
So


repeat{
 warp{
  do something ...
 }
}

yields twice in every iteration. Effectively running at half the speed.

For projects ported from Scratch, there is a common schema.
Body of the blocks created with "run without refresh" is wrapped in "warp". So in Snap project slows down with every consecutive warped block/procedure in a row.

hmm... we could take out the yield after warp, but then some things never would get shown. Another idea could be to check for and eliminate two consecutive yields...

It's not really consecutive warps that are the problem, right? It's a warp nested in the tail of another one. That's what makes two consecutive warps. It's a little like a tail call elimination.

hmm... you're right. But with the new Morphic architecture we might be able to optimize this if we tweak how yielding works. Then we simply could get rid of the yield at the end of warp. Let me think about this...

yep! In the new Morphic rendering architecture we can simply take out the yield at the end of warp, making these situations run twice as fast. Yay!!