FastLED palettes (from palettes.h) use gammas (2.6, 2.2, 2.5). Screens expect un-corrected colors, so we try to revert palette gamma correction in the browser.
The compiler has added gaps, to align our struct for hardware compatibility.
* made the gaps explicit
* added `__attribute__ ((packed))`, to ensure that the data layout is the same on all platforms (extensa, risc-v, 8266)
fix for #90
In principle its dangerous to write pixels from the webserver callback, but in this case we should be save - `suspendStripService=true` ensures that strip.service() is not active in the main loopTask.
* currentBri() is called for any setpixelColor(), so we can speed up everything (a bit) by allowing the compiler to inline which saves a few cycles of call/return overhead.
* aligned the function with upstream, and added another optimization by only calling progress() when a transition is active.
see https://github.com/espressif/arduino-esp32/issues/9043
"
The S3, C3, C6 and H2 that have HW CDC JTAG USB port may cause a delay when using HWCDC in Serial by activating CDC on Boot and selecting the USB Mode for Hardware CDC and JTAG. This happens when no USB application in USB Host side is started to receive the data sent by the ESP32xx.
The USB CDC buffer gets full and the Arduino HW CDC layer will timeout, by default 100ms, until give up trying to send the CDC data.
As a workaround, it is necessary to use HWCDC::setTxTimeoutMs(timeout_ms) and set it to zero.
"
this avoids heap corruption, by double-checking that "use global leds" is not configured, before trying to free ledsrgb[].
It is still a mystery why Segment::_globalLeds == nullptr.
sunset = 0 is a valid result, as the function result is in UTC and not local time .
Example: local time is UTC-8, local sunrise = 08:00am => getSunriseUTC() = 0.
So we cannot use "0" for "invalid". Using UINT16_MAX resolves the problem, and even allows to simplify calculateSunriseAndSunset() a bit.
