Release the json buffer lock as soon as we've finished serializing.
This should slightly reduce the number of lock collisions as the
response class isn't destructed until after the last packet is ack'd.
* File.readbytesuntil does not terminate strings. So the string buffer needs to be filled with zero's before reading.
* fix crashes (mem corruption) when ledmap file has too many / too few entries.
* initialize unused map places with "identity" (same led) mapping
before fix:
> Reading LED map from /ledmap1.json
> ("width": 60edmap1.json) ("height": 90edmap1.json)
> resetSegments 1 60x90
> allocLeds (0,0 to 60,90), 16200 from 0
> allocLeds (0,0 to 60,90), 16200 from 6
> deserializeMap 60 x 90 customMappingTable alloc 5400 from 0
after:
> Reading LED map from /ledmap1.json
> ("width": 60) ("height": 9)
> resetSegments 1 60x9
> allocLeds (0,0 to 60,9), 1620 from 0
> allocLeds (0,0 to 60,9), 1620 from 6
> deserializeMap 60 x 9
> deserializemap customMappingTable alloc 540 from 0
* setup: print free filesystem space after mount
* loop: forgot to actually reset the stale lock
* handleConnection: (8266) user messages in case of "heap too low".
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.
