WLEDMM: drawArc() is faster if it's NOT "super simple" as the regular M12_pArc code can do "useSymmetry" to speed things along on larger 2D layouts, but a more "complicated" segment likely uses mirroring which generates a symmetry speed-up, or other things which mean less pixels are calculated.
adding hints for the compiler for optimization.
In case your custom build complains about "const", just remove the keyword. based on e82f38e277, but going further :-)
* "const" class functions : function does not modify any class attributes ( --> "this" becomes const)
* __attribute__((pure)) : function return value depends only on the parameters and/or global variables. The function does not modify any global or static variables.
* __attribute__((const)) : function only examines arguments (no globals), and has no effects except the return value. This slightly more strict than "pure"
* hot: tells the compiler "this functions is called very often"
* cold: the opposite of hot
* mode_2Dfloatingblobs() improvements for large panels
* Segment::fillCircle() speed optimizations
* HUB75 hack (disabled by default): skip first fill(BLACK) when using double buffering (as the buffer gets cleared after each frame)
* cache width, height, and a few more values that are normally re-calculated for each pixel
* make normal sPC a bit faster
* Segment::fade_out() optimization
--> only active in FASTPATH mode, to preserve flash on small devices (8266)
--> code still needs some polishing
--> up to 20% speedup with some 2D effects (esp32, flash qio 80Mhz, -O2)
* optimized fadeToBlackBy() - don't repaint unchanged pixels
* made MIN_HEAP_SIZE configurable by build_flags
* specific error message when not enough memory for LEDs buffer
* fix compiler warnings (uninitialized vars, ambiguous functions calls)
* restore some lost function prototypes
* avoid negative pixel indices
* only use "fast" color_add when there is no risk of "overshooting" results
* minor optimizations
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.
* 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
* currentBri() is called for any setpixelColor(), so we can speed up everything (a bit) by allowing the compiler to inline which saves a few cycles of call/return overhead.
* aligned the function with upstream, and added another optimization by only calling progress() when a transition is active.
this avoids heap corruption, by double-checking that "use global leds" is not configured, before trying to free ledsrgb[].
It is still a mystery why Segment::_globalLeds == nullptr.
if random palette was used in the startup preset, all LEDs were orange until the first palette cycling happened.
This fix ensures that there is no all-orange palette initially.
I've found a code spellchecker, so this is what can be corrected easily. Changes are only affecting comments, readme and a few user-visible strings. So no functional impact expected.
index.js
- genPresets: Temporary for deterministic effects test: Set to 11/Raibow instead of 1/Random smooth palette
FX.cpp
- replace all millis() by strip.now
cleanup:
- version increase
- clean up debug messages
- minor fixes in platformio.ini
- fix compilation with -D WLED_DISABLE_2D
helping the compiler to optimize:
- a few more __attribute__((pure))
- fx.cpp marked a few local functions as "static"
