i love snap even more than scratch but the one thing that bothers me about snap is that it is slower than scratch for some reason why is that
Because snap was built using a ui engine that jens created, which runs purely in an html canvas. Snap is also developed by mainly on person (jens).
Scratch does all it's ui using html, css, and javascript. The rendering is also a whole lot more optimized than snap is. Another big difference is that scratch is being worked on by a big team of developers. There's so much one person can do.
The UI has nothing to do with differences in speed between Scratch and Snap. Both engines use standard HTML5 browser features. Scratch uses an ugly mish-mash of wanna-be web programming consisting of different DOM elements with heavy tweaking and customizations whereas Snap uses a similarly terrible home-grown framework inside Canvas. None of this matters for speed, because both graphics "engines" are just 2D cartoonish web-comics style microworlds, nothing fancy at all.
Some things are faster in Scratch because Scratch doesn't (have to) bother with complexities like variable scope, environments and generally the concept of first-class-ness. These expressive language generalizations come at runtime costs, especially since we're committed to making Snap's execution engine always user interactive ("lively"). examples where Scratch beats Snap are in purely imperative style, using loops to modify variables etc. Bear in mind, however, that many things are way faster in Snap than in Scratch. Examples are transforming media through higher-order functions and especially hyperblocks. This has consequences to kinds of projects which are easier to make (fast) in Scratch, such as games and variable-state intensive stuff, whereas media- and data-intensive projects are currently way faster in Snap.
Really? I've always thought Snap! was WAY faster than Scratch, so quite the opposite of what you're saying.
i agree but what i meant was that snap gets lagger faster than scratch
from my testing the biggest performance issues in snap are from the 2d canvas rendering. scratch doesn't have this issue because it uses webgl, and is likely coded somewhat better with many contributors. snap however has quite a bit of redundant slow code, which is difficult to get rid of because the code is frankly a bit of a mess. it's difficult to find when things happen twice, and it's all over the place.
in fact, a LOT of the slowdown is actually from rendering things that render only in the editor, not the project. you can often make projects significantly faster just by moving everything into custom blocks (as in, every hat block has exactly one custom block below it, that contains everything it actually does), because rendering the glow is quite slow.
last i checked, jens often doesn't accept large contributions. i still have a pretty large performance improvement sitting around in a pull request. (no, i don't see how anything i can add will be useful, because it'll need to be tested by someone else anyways. adding some measurements would still require taking my word for it)
also jens if you read this and don't believe me i'm absolutely willing to take the time to pull up plenty of evidence
Did you read the feedback you were given? Given how many significant changes have been implemented in snap since that PR, I suspect that your improvement has several unintended consequences that you can't see and has been filed away under "I can't use this"
(edit. I can't speak for Jens though. I'm adding this as an edit, just to clarify, because for all I know, he genuinely didn't see it and you're right /edit)
I honestly think though that what you should probably do is go build your own project that does what you want it to do, because you're probably not going to get the tool you want from Scratch or Snap!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.