Currently it’s a plain canvas, but this can cause a lot of lag or even freeze Snap!. So why not optimise Morphic’s logic?
This topic previously discussed using WebGL, but I realised that’s a bit of a bad idea
How fast is WebGL compared to plain Canvas?
Sure, it might be a bit faster, but I think that most of 
's slowness comes down to either the interpreter or morphic itself.
I think this is a nonstarter; Jens is very happy with Morphic as it is, for reasons having to do with “liveliness,” the ability to modify the code of a running procedure on the fly.
Yeah, I did put morphic’s potential for slowdown in my reply, although the main info I wanted is how fast WebGL is compared to Canvas2D.
Canvas for the majority of browsers is now hardware-accelerated.
For a typical 2D use, WebGL may not gain any performance.
Gemini:
WebGL 2D offers superior performance over Canvas2D for high-density rendering (thousands of particles/objects) and complex visual effects, leveraging GPU acceleration to maintain high FPS. While Canvas2D is faster for simple, low-draw-call tasks due to lower overhead, WebGL excels in handling large, dynamic datasets by minimizing CPU-to-GPU communication
Yeah, I did put morphic’s potential for slowdown in my reply
It’s not mainly a matter of speed, but of what’s possible. I’m not an expert on this, but Jens’s problem with basing Morphic on something else has to do with seeing what’s happening in layers below the visible one, I think. Maybe he’ll explain better…
They’re just proposing morphic be rewritten to use webgl instead of canvas2d. The whole morphic api would stay the same, it’s just what it’s being rendered to is different.
I agree with @dardoro and @d016, webgl wouldn’t give that much of a speed increase, and the slowdowns are likely not because of rendering, but instead just computing. Though it would be interesting to see if there is any difference.
I’m not sure how to even begin optimizing morphic. Maybe use some HTML, like Scratch? But at that point you might as well use Blockly.
I could be wrong, but I think that’s what snap 10.4 did (?)
What? No, morphic still does (almost) everything on a canvas.
I meant general optimization in some way.
I remember reading that morphic was updated to be faster in a big snap update (can’t remember which one, but not 10.4!)
It’s better than before, but still not fast enough.
I think the rewrite was 6.0, and there was this in 10.4:
- “Quicksteps” Evaluation - Dynamic Scheduling: Keep stepping non-animating processes between animation frames, makes “warp” and “turbo mode” largely obsolete for number crunching and improves musical thread synching
- Floating point precision random numbers - pick a random float by entering an integer with a decimal point into at least one of the “pick random” reporter’s input slots
- reduced animation speed from 67 fps to 60 fps
I’ve optimized Morphic (Morphic2) in 2020 for Snap6.
Thanks for clarifying.