If the segment is wider than 20 pixels, we optimize calculations due to symmetry - for smaller arcs the result looks better without optimization.
As a side-effect, we have enough computing power left to go through the complete circumference, avoiding holes.
as it turns out, the "_t" functions (from wled_math.cpp) are about 3 times (!!!) slower than the standard functions.
* mapping modes : Arc and Circle
* effects: 2D Drift, 2D Drift Rose
* use "float" math only - sinf(), cosf(), roundf()
* use fewer "rays" for medium-sized matrix (<=32 pixels wide/high)
* ray drawing optimized to use fixed point
up to 80% faster on esp32 and esp32-S3; -S2/-C3 should also see benefits, as these do not have floating point support in hardware.
Release the json buffer lock as soon as we've finished serializing.
This should slightly reduce the number of lock collisions as the
response class isn't destructed until after the last packet is ack'd.
* File.readbytesuntil does not terminate strings. So the string buffer needs to be filled with zero's before reading.
* fix crashes (mem corruption) when ledmap file has too many / too few entries.
* initialize unused map places with "identity" (same led) mapping
before fix:
> Reading LED map from /ledmap1.json
> ("width": 60edmap1.json) ("height": 90edmap1.json)
> resetSegments 1 60x90
> allocLeds (0,0 to 60,90), 16200 from 0
> allocLeds (0,0 to 60,90), 16200 from 6
> deserializeMap 60 x 90 customMappingTable alloc 5400 from 0
after:
> Reading LED map from /ledmap1.json
> ("width": 60) ("height": 9)
> resetSegments 1 60x9
> allocLeds (0,0 to 60,9), 1620 from 0
> allocLeds (0,0 to 60,9), 1620 from 6
> deserializeMap 60 x 9
> deserializemap customMappingTable alloc 540 from 0
