* fixed a bug that caused wrong behavior with segment mirroring
(effects must use virtualHeight() / virtualWidth() instead of height() / width())
* added image blur as an option (second slider)
* added very basic error reporting for users
* up to 25% faster, especially with big animated gifs
* made all local variables "static" (don't pollute global namespace)
* drawPixelCallback: cache calculation that do not depend on x/y position
* reduced memory allocations on boards without PSRAM, to avoid crashes
The segment copy constructors can temporarily exceed the budget of MAX_SEGMENT_DATA. The original segment will be de-allocated a few milliseconds later.
This change introduced an "overdraft" budget of 50% that can be used for temporary segment copies.
prevent errors / crashes when drawing "i" images from a preset.
- prevent out-of-bounds writing (segment smaller than image)
- make sure that segment properties are cached correctly
- always do "show" when strip was triggered (avoids lost frames)
replaced CRGB -> RGBW32 conversion with FastLED native ``uint32_t(c) & 0x00FFFFFF`` operator. `
`& 0x00FFFFFF`` is needed to cut out the "alpha" channel, because the fastLED operator return RGBA not RGBW.
--> slightly faster
* moved sPC and gPC functions out of their .cpp files into FX.h, so the compiler can optimize better.
depending of effect used, this gives a 2% up to 8% speedup.
this change was somehow lost - ColorFromPaletteWLED existed in colorTools.hpp (for fast inline) but was missing in colors.cpp (WLEDMM_SAVE_FLASH fallback).
Enable building color correction code if you really need it.
The effect of color correction is less noticeable on HUB75 than on ws2812b, however it can reduce your framerate by up to 10%.
For maintainers of custom effects: replace "return mode_solid()" with "return mode_oops()"
Effect errors fall back to Akemi (2D) or Rainbow(1D) instead of SOLID ORANGE.
* a few new error constants
* WLED_O2_ATTR - ask the compiler for stronger optimization of a single function
* WLED_O3_ATTR (WLEDMM) optimize even more
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
accroding to the docs of setBufferSize() and svbuf():
> setBufferSize() has to be called right after opening file before any other operation!
so changing buffer sizes on an already opened and partially read file can cause file corruption as the internal buffer is exchanged "mid-flight".
Fix: move all f.setBufferSize() so they appear directly after f.open().
previously gPC cached busses were disabled in slowMode (one pixel mapped to several outputs). However this should not be needed, because the first copy found should be like all other.
* optimize loops that scan through all busses
* small speedups for Bus::autoWhiteCalc()
* small speedups for ColorOrderMap::getPixelColorOrder()
thanks to github Copilot for giving me the right ideas for this optimization
* bug: logf(temp-10) result becomes NaN when kelvin < 1200
* bug (RISC-V only): parameter of Bus::setCCT must be signed, to avoid undefined behaviour
* minor optimization by replacing constrain() with min(max())
