I have been using snap for a while for in my ap comp sci classes and almost everyone in class are having trouble with lag and low performance even with simple programs? Similar programs such as scratch are able to handle this easily. Is this a problem with computers? Or is it with the servers and limitations?
Scratch 3.0 was made mostly by Google. Google has a lot of money to spend on bug fixing. Snap doesn't, and so Snap has worse performance.
Hi, welcome to the forum.
It's hard to know how to answer this without looking at a specific program, and without knowing what browser version you're running. We're faster than Scratch at some things and slower at others, but overall I don't think we're so bad.
Server issues would affect how long it takes to load your project in the first place, but once loaded, it runs entirely in your computer. Recently there was a Chrome bug that slowed us down; if you're using Chrome, make sure you're at version 78.
Hi, it might be good to know that some favorite patterns that you and your students might have learned in Scratch don't work so well / fast in Snap. In particular color collision detection is something that I'm seeing in a lot of Scratch projects, and that's noticeably slower in Snap. If you and your students are using blocks like touching color? or color touching color? - especially inside forever loops, it's a good idea to replace that with sprite-collision detection instead, enhanced by using nested sprites. This is probably the single most dramatic effect when you're experiencing "lag". I'm actually contemplating to take out color collision detection altogether, because I think it's both a questionable idea and it doesn't work very well.
Can you guys just make it save automatically, I have lost countless hours of work due to random crashes deleting huge portions of my projects...
There is a common source of inefficiency of "color touching" functions. It's the "stage.colorFiltered", usually used this way
if (thisObj.colorFiltered(color1, tolerance).isTouching(
stage.colorFiltered(color2, thisObj, tolerance)
Neither "colorFiltered" nor "isTouching" are native canvas API. They are implemented by "brute force" image data array processing, byte by byte.
"colorFiltered" scan and modify ENTIRE stage thumbnail (pen trail + stamps of all sprites) without any chance for early succes or failure. This step is not necessary. "isTouching" can be modified to accept "color" parameter. Then "thumbnail" image data can be compared to "color" instead of 0.
Also "thumbnail" generation can be limited only to sprite with intersecting bounds.
"Retina" mode and large stage size can aggravate this problem by factor of 4 (or square of the enlargement).
Rough implementation of this ideas, for microbenchmark with 50 small sprites, show 3 to 6 times speed gain.
After I begun using Snap! instead of Scratch, I did notice what has been explained above by Jens, so I have soon learned to completely avoid using the touching color? and color touching color?, so I would not mind if those two were abandoned from Snap!
BUT if they can be rewritten as proposed above to gain speed up to 3 (6) times, then they don't need to be abandoned from Snap after all, I guess.
yep, that's an accurate analysis, @dardoro, although I'm not so sure about the exact performance increase that we'll eventually get. Recently I've drastically optimized general collision detection, which also - slightly - improved color collision detection, but left more optimizations for color collision detection open until after we gathered some experiences with the new mechanisms in place. short-circuiting color collision is on my list, and it'll be interesting to find out whether that'll improve things somewhat. I have to admit, however, that my heart sinks whenever I look at projects that actual kids make in actual schools. They're often so full of color collision detection that it seems like that's the only thing teachers ever show them.
I must admit that, as the FOREVER IF block that I resurrected for my students, some blocks are very useful when you teach computer programming in specific environments. Using FOREVER IF or TOUCHING COLOR at the beginning make the project very short and you quickly get an interesting result (remember that the attention span is about 20 minutes). Then, when you explain that there are advantages in using other blocks (e.g. reducing a lot of scripts to just a single script by using FOREVER + IF instead of FOREVER IF) you will quickly abandon those "start up" blocks, but you have not lost your new little (or big) programmers. This is good redundancy that has always been present in Scratch and made it a successful environment. Who is using the IF ON EDGE, BOUNCE block other than for their initial Pong/Arkanoid projects?
Glad to report that as of right now we've significantly optimized color collision detection in today's minor Snap! release (v5.3.8)
Not really. Google made blockly, but Scratch 3.0 was changed a lot by the ST.
Anyway, Google's money all goes into introducing bugs into Chrome.
that break Snap!
Yes! For example, on my chromebook, everything says "Reload Frame" and "View Frame Source" in the chrome right click menu, even when there is no iFrame. See
Try it for yourself. There is no iframe.
Sorry for the very late reply, but I have brought these up to my peers and mentioned the following solutions to the teacher for future classes, and for the most part it's working (well better than before). Thanks for all your replies.
edit: Also I don't believe it's because of the local PCs as they are pretty powerful, packing an 8th gen i7 and dedicated graphics.