on top of. But yeah.
they are inside!
Some of them. But mostly it's
Ah yes, block dimensions
Disappointingly, when I get rid of all the IFs, it doesn't really get faster. :~(
When I try taking all the code out of SET PEN LIGHTNESS TO, so it doesn't actually change anything, it still takes about half the time it takes to do the real work. So I guess doing anything in Snap! is going to be slower than not, especially if a lot of block invocations are involved. (1000 of them, in your test code.) But it shouldn't really be 1000 times slower. More research for me to do.
So, my computer is a little slower than yours; here's the latest timing data:
- Using the HSV primitives: ≈20ms
- Directly calling SET PEN LIGHTNESS: ≈850ms
- Using an explicit dispatch table: ≈1000ms*
- Searching Snap!'s own list of custom blocks in JS: ≈2300ms
* This number was measured using a test version of the dispatch table that has only 2 entries, so it'll probably be somewhat slower with all 27 entries included, but not infinitely slower because the search uses the primitive FIND FIRST block.
If the dispatch table performance holds with a larger list, what this means is that the biggest component of the time is those 850ms doing the actual work, in SET PEN LIGHTNESS. I hope I can speed that up.
A good bit of the time goes into trying to make sense of the desired effect when the user switches color spaces midstream. That is, if the color was last set in HSV or RGB terms, and then the user asks to set the lightness, what should happen to the hue and saturation (especially considering that HSL saturation is a different scale from HSV saturation)? So basically I convert the old pen color to HSL before setting the new lightness. It'd be nice if JS supported HSL!
isn't it just to make reading easier?
That's the problem I'm trying to solve.
wouldn't that be a little misleading, when on earth would anyone need to do this? Why repeat a 1000 times? Sure, it'll take 2 ms per lightness check, but the delay caused by the maximum framerate(say 60) is 17 MILLISECONDS
I don't get it, is everything just a warp block in disguise?
Sigh. Go back to the beginning of this thread and read what it's about.
well that explains a lot. but if the pixelation is a default, then it is a 480 * 360 absurd insanity that would take time to load in the MILLIONS of milliseconds?
Try running the actual project.
that's 20 minutes, the project takes 20 seconds. You are off by a factor of 60.
Sigh. The project uses the primitive HSV blocks, not the Colors library, because the latter would be too slow. Please don't reply to this until you have read the entire thread carefully.
ahhhh
Such extremely large procedures speed up considerably with the option "Live coding support"
Thank you! Good call. That gets the SET PEN TO LIGHTNESS loop down to around 250 ms, and the interface via the general SET PEN [LIGHTNESS] TO down to around 400ms. Still not good enough, but a huge improvement.
what’s that?
The funny thing is, making the axis actually took a lot more time than making the graphing part. The graphing part just colors the output of a function, while the axis has to find the nearest 'nice' (1,2,5) number and use that as the tick mark divisions, then find another 'nice' number to use as the starting point.
