Rotating bitmap turtles (introduced in FMSLogo 6.25.0) are too slow to be used safely, especially at high zoom rates. In particular, zooming by a factor of 16 makes FMSLogo virtually unsuable.
Most of the time is spent calculating the scale/rotation transformation or doing bilinear interpolation. It should be possible to precompute the result of these operation and use a relatively fast blit (the same as the non-rotating bitmaps).
How Reproducible:
Every Time
Steps to Reproduce:
repeat 100 [ fd repcount rt 91 ]
home
bitcut 100 100
cs
(bitmapturtle "true)
zoom 16
rt 1
What Happens:
The bitmap is drawn very slowly and FMSLogo cannot be halted while it is drawing.
Expected Result:
The bitmap should be drawn quickly enough that it doesn't make FMSLogo feel sluggish to run simple commands, like RT 1.
I am back-marking this bug as fixed in 6.33.0, when I made a lot of performance improvements to rotating bitmap turtles, the most significant of which was to read the pixels of the bitmap into a flat array and cache it, instead of accessing the pixels through the GDI API.
The repro steps no longer function, as turtle 0 (the clipboard bitmap) is no longer permitted to be used for a rotating bitmap turtle. The following now works.
In 6.32.0, it took about 60 seconds to render the screen on my machine during which time FMSLogo would be marked as "Not Responding". And if the screen window was occluded and reshown, it would be another 60 seconds before FMSLogo would accept any further input. This is clearly unusable.
In 6.33.0, rendering the turtle is pretty fast on my machine and the same thing takes about 10 ms.
I don't doubt there are zoom factors, bitmap sizes, and turtle counts that can cause FMSLogo to be sluggish, but it's nothing like it was. If there are still performance problems, it would be a different bug with different repro steps and a different solution.