Snap! is slower than Scratch? or My code is Urgh!

i saw a project in scratch website that mentions Snap! I tried and yeah its definitely more advanced. but performance? its bad... I mean.. im not judging Snap! for being slower(AND Im not even sure about that).. its just.. what I experienced.. i dont know if there is a desktop version but I used browser version to create a simple 2d sine wave visualiser. its really slow compared to same Scratch project. That was my first project so Im not sure if i did something wrong. I used Warp blocks and stuff.. yeah there are a lot of loops but my point still stands.. any help appreciated!

Some stuff runs a LOT faster than Scratch - other stuff doesn't.

Especially stuff that is just copied over.

But in some cases, the algorithm written in Scratch can be re-done to give faster results.

Some things have been optimised in Scratch - some different things have been optimised in Snap! (and that list normally increases each month :slight_smile: )

It loads perfectly fine, but I don't see anything bad happening in the project and everything is running smoothly.

Usually when the project has troubles loading, then it's a Snap! Bug, but if nothing is happening in the project or the project is slow after it started It's sometimes something that happened with the code.

Or prob your computer

In general, Snap! runs slower than Scratch. I think it might be due to the fact that Scratch uses HTML elements while Snap! draws everything to a canvas, but don't take my word for it.

I see. cant wait to play with new updates of Snap!

and scratch 3.0 uses a WebGL renderer which probably means it also uses the GPU for rendering which probably means it renders things faster. Especially for sprite effects.

Painting the whole screen pixel-by-pixel is instantaneous. But calculating pixels color for 4 waves took 10s!!!
2D sine waves script pic (1)

I didn't see anything obviously slow in "calculating value". Just a sinus() calculation, interleaved with a few "if" x 7000.

I did a bit of experimentation, and by far, the biggest slowdown is caused by accessing and updating variables/lists.

thanks for the answers! i will try to use 1 list and also make the "deciding between 4 different wave types" without using if elses. i will share the progress if it works

storing all data in 1 list was a bad idea. picking data from long string causes more accessing to list even tho i managed to remove if elses. so its worse :no_mouth:
im desperate lol

Shift :gear: menu, experimental :ballot_box_with_check: "Live coding support"

You do know that lists can contain lists? For example,
2D sine waves #optimization fail script pic
2D sine waves #optimization fail script pic (4)
2D sine waves #optimization fail script pic (2)

What does that do, exactly?

@legoman3.14 @dardoro These are Definitely helped alot! its taking 4 seconds to visualise 30 waves!. too bad "live coding support" is always disabled in default. so you have to go inside and enable it manually always. but still thanks!
here list in lists code (dont forget to enable "live coding support")

it works fine for me

:gear: menu, :ballot_box_with_check: "Flat line ends"
This makes the pen trail ends end flat, instead of with a circle.

Tere is a project that forces this EXPERIMENTAL setting...

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.