* 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.
Seems like a 10 microsecond delay on boards like the ESP32-P4 may not be enough, causing some issues with UDP audio sync being delayed or appearing "buffered". Oddly 10 microseconds was fine with the ESP32 and ESP32-S3, so it may also be an underlying IDF v5.3 change.
Practically, 10 microseconds or 100 microseconds isn't a real difference when we're dealing in frames per second.
* use a more meaningful max universes limit of 112 (safe up to 128x128 pixels)
* accept more universes, but only track sequences for the configures max universes
* made e131LastSequenceNumber[] local (its only used in e131.cpp)
* make XY() and _setPixelColorXY_raw() const (minor speedup)
* segment is a struct not a class: friend class Segment --> friend struct Segment
* fix missing braces around two macros
* use non-throwing "new" where possible
* improve robustness of transition code
same issue as with https://github.com/Aircoookie/WLED/pull/4386
waiting on bus to finish updating before file access fixes the glitches.
this issue is only present on S2 and C3, not on ESP8266 or dual-core ESPs, the fix is only applied for these two.
If the source never sends the push flag, WLED buffers the update but
never publishes it to the LEDs. This causes the confusing case where
the peek display shows one thing but the LEDs themselves something else.
Add a static flag that tracks if we've seen a push from the source;
until we do, apply every update as soon as it's received, per the DDP
specification.
This disables bus caching (and related speedups) while receiving realtime UDP pixels.
Its still totally unclear to me what happens, and why disabling the cache solves problems.
BusNetwork stores original colors (not modified by global brightness), so `restoreColorLossy(strip.getPixelColor(i), stripBrightness);` was actually restoring brightness twice when running network output. This lead to preview flickering.
* re-organized default_env by board type
* added a note saying if HUB75 support is included
* esp32 buildenv cleanup (removed not used flags)
* env:esp32_4MB_PSRAM_M deleted
* flash usage statistics
