during testing at low brightness I noticed that gradients can be "jumping" in colors quite wildly, turning a smooth gradient into a flickering mess. This is due to the color hue preservation being inaccurate and a bit too aggressive. This can be seen for example using a gradient palette and "Running" FX.
Removing the hue preservation completely fixes it but leaves color artefacts for example visible in PS Fire at very low brightness: the bright part of the flames gets a pink hue. This change is a compromise to fix both problems to a "good enough" state
* moving color_blend, color_add, and color_fade to a seperate file, to allow the compiler to inline the functions.
* inlining slightly increases firmware size - original non-inline functions get used on 8266, or when WLEDMM_SAVE_FLASH is defined.
For 8bit blends, we adopt the new blend8() logic from FastLED.
The WLED color_clend function is based on very old FastLED code, that was replaced 3 years ago due to serious rounding problems.
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
* 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
.... actually we undo gamma adjustments, because screens (laptop, pad, etc) will apply their own gamma corrections.
Activate in LED settings: "Use Gamma correction for preview"
Colors in WLED are sometimes gamma corrected, sometimes not. This change tries to make the best out of the color mess, but its still not working properly in all configurations.
* getpixelcolor: attribute pure - it reads memory, but does not write
* some optimizations for SEGMENT.blur() and SEGMENT.fadeToBlackBy()
* FX.c:pp remove double calls to blur() and fade_out()
* FX.cpp: SEGMENT.setUpLeds() added to effects, to enable LED buffering (safe some time because getPixelColor does not need to access NeopixelBus)
* a few other optimizations to safe time and avoid "expensive" operations
* set I2C bus speed to 400kHz (default is 100Khz)
* a few other small optimizations and tweaks
* pio: esp32 V4 builds use "patch5" toolchain version, which contains a few bugfixes especially for memory management.
* make local functions "static"
* use fast_ int types where possible
* use native min/max instead of MIN/MAX macros. Macros evaluate each parameter TWICE!!
* adding __attribute__((pure)) and __attribute((const)) to help the compiler optimize
* ws.cpp: reduce max "live leds" in fastpath mode
* colors.cpp: disable gamma calculation if CIE table mode is active (WLED_USE_CIE_BRIGHTNESS_TABLE)
* fx.cpp: small improvement to FreqMap, and bugfix for effects that modify binNum / maxVol
* pio: update for Line-In shield pins (final hardware version)
