Well, from what I've heard, you've taken a look at my rendering engine. If you look inside of the blocks, most of the source code is either entirely or mostly in JavaScript. This does come to a cost (like when you need to wait for yielding (waits before it finishes) block to finish), but you can compare this to when I first started trying to make one. It was so laggy, even when I was drawing at fractions of the resolution (with no lights or even shading!)
Advanced topic examples:
https://forum.snap.berkeley.edu/t/executing-rings-with-js/1687/22
And if you don't believe them:
https://forum.snap.berkeley.edu/t/draw-pixels-instead-of-dots/1684/3
All right, I had more time today and converted the Touch Ground block into JS but it's slower than warping it! Does the entire project have to be converted before any changes take effect or am I doing something wrong?
Usually, for the biggest performance benefits, you must convert large chunks of blocks into JavaScript. Typically anything object related (like creating things like lists and manipulating them), things that are very complex (made of several blocks and very complicated), and things that are done iteratively (for/foreach loops) are far faster in JavaScript. I think iterations are likely the biggest impact on your project, so what I said is ordered from least impactful to most. Converting like one or two random blocks that are frequently used wont have as much of an impact as converting some logic that manages projectiles iteratively. I had one example where I computed distance between some point functions in Snap! for every time I needed to continue ray steps. I converted it into JavaScript and the performance was so much better.
This optimization does involve abstracting away from using Snap! blocks though, so as long as the interface of using the blocks makes sense, the inside typically doesn't need to be perfect and clean, although it is appreciated if the code is well commented and written.