gifdecoder bugfixes, up to 30% speedup, and minor improvements
- several optimizations for the drawing a single pixel (hot path)
- Image mode now runs correctly on 2D/matrix layouts with mirroring.
- added an extra slider for Blur intensity;
- improved per-segment scaling/upscaling and memory-aware decoder behavior on low-RAM devices.
- Robust filename validation, graceful failures for missing/unsupported files or low-memory, better decoding error handling and playback cleanup.
- Better user messages
open ends (will not fix in this PR):
* ".gif" filename compare should be case-insensitive - ".GIF", ".Gif", ".gIf" should be accepted.
esp32 does not have "stricmp", so we might need a custom solution, maybe with a utility function that internally uses tolower(c) before comparing. Also strip leading / trailing blanks from the filename.
if seg.name is empty or shorter than four characters, ``strlen(lastFilename) - 4`` underflows (size_t), so the pointer passed to strcmp lands far before the buffer and triggers undefined behavior.
This patch catches too-short segment names and aborts decoding.
* 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
