changes from 3.50 to 3.6.0:
* bugfixes
* removed "register" keyword
* some speedups
* explicit bool() and uint32_t() operators, see https://github.com/FastLED/FastLED/issues/819
FX.cpp: bugfix for "wled00/FX.cpp:4906:36:
error: cannot convert 'CRGB' to 'uint32_t' {aka 'unsigned int'} in initialization"
turns out that fastLED 3.6.0 has an explicit uint32_t operator that returns RGBA, however 3.5.0 does not have this and the conversion returned only the "red" component".
turns out that fastLED 3.6.0 has an explicit uint32_t operator that returns RGBA, however 3.5.0 does not have this and the conversion returned only the "red" component".
it seems that SEGMENT.blur() is the main bottleneck for many 2D effects.
This change optimizes performance of the function:
* avoid to re-write unchanged pixels
* early exit when blur_amount == 0 (=nothing to do)
* use _fast_ types where possible
I've seen up to 20% speedup with this change.
power estimation results from estimateCurrentAndLimitBri() were too low (example: estimated 1.3Amp, measured 1.6Amp). This change corrects the power calculation. Due to the changed behavior of getPixelColor, powerSum must be used as-is, not scaled down again by brightness.
minor optimizations that give up to 10% speedup in my tests
* use "fast" integer types (where possible)
* replaced _bri with _restaurationBri (no use of globals)
this optimization avoids to apply brightness two times .
NeoPixelBusLg has already applied global brightness at sPC. Due to internal working of the Lg bus, its sufficient to only post-apply scaling, and set the new (scaled) brightness for the next frame.
I still see strange crashes in setPixelColor/GetpixelColor, which ssem to come from race conditions between async_tcp (change presets) and looptask (strip.service).
To make the situation better, its important that any global pointers are reset to NULL immediately after free().
* Avoid uint16 underflow in width() and height(): stop > start is possible, and means "inactive segment".
Without these checks, it was possible that width() and height() produce VERY large values due to underflow.
