Hat blocks are MUCH slower for a large amount of blocks than a custom block

warp doesn't change anything, it's not the issue here
if/else blocks don't yield, warp wouldn't do anything on them anyways

ok, so instead of having one big warp around the whole script, have each warp inside all of the inputs

[scratchblocks]
warp{if<> then{ warp{if<> then{warp{if<> then{
[/scratchblocks]

warping is not the ideal solution since it pauses every other running script until the warp finishes

oh, really?

Wow, you're on a reporting spree. Did we annoy you with anything? Let me reiterate that this forum is not a medium to drag me into discussing technicalities, much as this seems to be the thing you're really interested in. See, what keeps disappointing me is that over in Scratch y'all just make awesome projects, and here y'all just want to make it into the Snap! dev team. You'd think that with lambda, HOFs, proper tail recursion, lexically scoped local variables, hyperblocks, custom functions, prototypal inheritance, meta programming and a rich environment of APIs you'd come up with a wealth of awesome original projects. This isn't to say there aren't may wonderful, astonishing projects in Snap!, but the discussions in these forums are almost exclusively around ... technicalities and showing off "advanced" googling.

Let me give you a couple of examples: The other day I was asked by a curriculum writer whether it would be possible to use Snap! to teach about QR codes. Before saying "sure" I went ahead and searched for a project and found ... exactly none in Snap. Then I looked in Scratch and found overwhelmingly many of them. Examining some of the better ones in Scratch and comparing them against the QR code spec I was once again shocked how terrible it is to transcribe algorithms to Scratch, because for every function you need to make a global variable and then a custom command block that works on it, and everything needs to be inside nested loops working on global variables all the time. Yet this is what happens and many people are creating awesome stuff that way. You know, not just impressive games, but actual hard computational projects. They're not put off by Scratch's impoverished abstraction capabilities, and in their project notes they're not complaining about variable scope and of the need to write spaghetti scripts. Yet here we are in Snap!, where you'd think that with HOFs and Hyperblocks it would be pure joy to delve into such projects. But instead ... what comes out of all of this is just a bunch of dudes wanting to talk technicalities. Man, I'm so frustrated by this.

Similarly, projects like 3D wireframe models are all the rage over at Scratch, and all but totally absent here in Snap!, even though with Snap's built-in support for vector- and matrix operations they seem like a natural area to explore. But - again - all I'm seeing is folks nitpicking about "compiling" blocks and how creating absurd levels of nested statements is "lagging". Geez.

The same applies to project ideas like gesture recognition, vector graphics, sound synthesis, OCR, and many many more. Instead of surprising us with what you can accomplish when advanced CS concepts meet fun challenges all I'm ever reading here is kids discovering JavaScript and wanting to drag me into discussing Morphic.

https://snap.berkeley.edu/snap/snap.html#present:Username=d4s_over_dt4&ProjectName=prime%20spiral%203d
https://snap.berkeley.edu/snap/snap.html#present:Username=d4s_over_dt4&ProjectName=matrices

i'm on a reporting spree because i'm actually trying to make a project and keep running into these issues. if i wanted to be on the dev team i would just be looking at the code and submitting pull requests.

i genuinely have a project where i got to just with the bare minimum for typing text (put letters and backspace) and that was enough blocks for it to start lagging if i type fast.

snap is great, i like the lambdas and continuations and all the crazy things that can be done in it, but i don't like having to think "right, this block has that bug, so i need to do this", and i definetly don't want it to stay that way when i'm introducing other people to it.

THERE ARE NO NATIVE SNAP BLOCKS FOR PRESS AND RELEASE EVENTS ONLY CLICK EVENTS WHICH ARE RIDICULOUS AND HARD TO TRACK AND SPAWNS A TON OF LAGGING PROCESSES IF YOU MULTI PRESS
on contrast,i can do all key processing in 3 lines in javascript

Are the people you plan on introducing to it going to try to push the envelope as much as you seem to be keen on doing?

BTW Could I ask what this project is that your working on?

key pressed is a press event. it says press. pressing multiple keys doesn't lag unless your script is long and laggy. you can use wait until not key pressed to detect when it's no longer pressed.
didn't i tell you this already before?

i don't think a textbox with the WRITE block is pushing the envelope, or trying to sort sprites by name.
the project i'm working on is some snap os thing, main thing i'm going for is being able to add new programs and run multiple programs at the same time (it's really just adding and cloning sprites, and a window program that other ones can use)

yeah, none of the common forumers actually make project projects ;(

wait, snap has this? (sorry)


Sorry, Jens

...
Jens JUST SAID he wants actual projects. Not javascript technicalities

i've been trying to work on quite a few things but i usually run into performance issues or bugs very quickly, it also just takes time to make good projects and i'm not going to release bad ones

i release the libraries and talk about the technical stuff because i need that before i can make impressive things. scratch has a lot of technical projects, but that's largely due to the long history of being able to share projects, the great performace, and how little it changes. i haven't been on snap long but if i remember correctly the community website is pretty recent and doesn't really have much for finding interesting things and ideas (social media elements have a lot of downsides, but snap hasn't given the useful parts)

you might like to check this out:

thanks, but i already have windows and i prefer how they work (in enough ways at least)
either way i feel like discussion of my project and a lot of the stuff here is off topic

Scripts in Snap! "glow" up when they run. Computing the blurry halo and displaying it takes a little time as opposed to running an invisible script inside a custom block definition. And of course, constructing a 24-layers deep nested structure doesn't much help for any of that.

Hey, I've just now conducted a little quick experiment for a a very basic text box widget project that lets you write and edit text and render it inside user-constrainable bounds at a user-specifiable size:

Is it just my mighty new laptop, or does it run halfway decently on yours, too?

That rotatable cube project is wonderful, thank you!

i tried it on my laptop, and didn't notice at first, but i figured out why.
it seems that most of the effect is apparent when the browser runs at high framerates.
on my desktop, in firefox about:config, i have layout.frame_rate set to 240. the effect becomes very obvious then. without this it seems to mostly just not register keys instead of queuing.

even weirder is that it seems to drop inputs if the sprite isn't open, but queues them if the sprite is open.

however, the effect is still there in the simple text box project regardless of framerate, just somewhat less of it. it's still enough for it for me to notice how unresponsive it is while typing, my test project is just exaggerated.

if the issue is calculating the glows, maybe cache the image?

also i have a very nice cube too, i sent it before in the forums but i'm not sure if you've missed it.
i think everyone could do with some more cubes