How to limit Height ou reduce memory usage on ESP32?

[FrenchLab47]

Hello,

Your library displays GIFs perfectly on a double RGB Led matrix (128 x 32) controlled by an ESP32 But as I load a large code and many libraries (server, clock, audio spectrum, etc.), my memory space is very limited.

My problem : With #define MAX_WIDTH 320, I cannot compile my code (overflowed by XXXX bytes) With #define MAX_WIDTH 128 instead of 320, it's better, but a few bytes of memory are still missing to compile.

If I halve #define MAX_WIDTH 64, the code compiles fine and the images display fine. Even the 128px wide one (I understand that it doesn't cut out the images).

As I read your comment: Designed to decode images up to 480x320 I would like to know how to adjust these two values WIDTH an HEIGHT (480x320) to the actual size of my matrix (128x32 or 128x64)? Or limit the memory for these values?

Thank you so much.

[bitbank2]

The height doesn't affect the amount of memory used since each line is emitted one at a time. If you're running out of memory on the ESP32, then re-use the GIF structure for other purposes. It needs about 22.5K of RAM, but only while decoding. You can use that memory for something else when not using the GIF decoder. Another way of describing this is a "memory pool". For example:

static uint8_t my_memory_pool[24000];

AnimatedGIF pGIF = static_cast<AnimatedGIF >(my_memory_pool);

Then use the memory for something else that doesn't need to run at the same time as the GIF decoder.

Hope this helps. L.B.

[FrenchLab47]

This is a very good idea, I will try this. Thanks for your help.

[marcmerlin]

@bitbank2 memory on ESP32 is complicated, but basically, memory available for global arrays, is only half the memory actually available. Have a look at the slides on http://marc.merlins.org/perso/arduino/post_2020-01-14_LCA-2020-Talk_-ESP32-Memory-Management_-Neopixels-and-RGBPanels.html

This is what I did to my old fork of the library, I switched everything to malloc. Sorry, this is not a single CL, I wrote it over time

• https://github.com/marcmerlin/AnimatedGIFs/commit/0c6191181ec3a6b7061afcb9acf1512a7a19a358#diff-1c6b5b8854f2713658794a513e0149a7861b1aae2755e52dbb1c78a1900b2f2b
• https://github.com/marcmerlin/AnimatedGIFs/commit/2715fe2fccc666d667ad5932c75414d0cbe875e6#diff-1c6b5b8854f2713658794a513e0149a7861b1aae2755e52dbb1c78a1900b2f2b
• https://github.com/marcmerlin/AnimatedGIFs/commit/c2dc4c78d3fe8d0cc45d8aa621457466a48d4713#diff-cca9dc0aaf37dcf8e83c111f403400c9f29a228fbfad3c5f62eed507f8608664
• https://github.com/marcmerlin/AnimatedGIFs/commit/1750be0fb5062c8f29f4535e7e08e60036746032#diff-cca9dc0aaf37dcf8e83c111f403400c9f29a228fbfad3c5f62eed507f8608664
• https://github.com/marcmerlin/AnimatedGIFs/commit/ad21ba5522d75cfd02fe517a081fbb15eb4de1a9#diff-cca9dc0aaf37dcf8e83c111f403400c9f29a228fbfad3c5f62eed507f8608664

I also later updated mallocordie to allow allocating in PSRAM to further save main memory

[marcmerlin]

mallocordie: https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos/blob/38a137e3ac54d4f0b8d7a11ca99d2061cbbf86b1/neomatrix_config.h#L885

[bitbank2]

Instead of changing the library code, why not allocate the whole GIF structure with malloc? That's why I wrote it the way I did. You can define it as a static or allocate the whole structure in one shot.

[marcmerlin]

note that those patches are to an old version of the library. With the current one, using one malloc makes sense. however, because memory is fragmented on ESP32, it's better to malloc each structure you need than malloc a big contiguous pool (which might not exist as one contiguous block). In case you're curious, I maintain an old fork along with SmartMatrix and memory is tight on ESP32 when you reach resolutions of 128x64 http://marc.merlins.org/perso/arduino/post_2018-07-13_AnimatedGIFs-for-SmartMatrix-or-NeoMatrix-_Neopixel-WS2812B_-from-SDcard-or-SPIFFS_-on-Teensy-3_x_-ESP8266_-or-ESP32.html

I am now running the same (old) gif decoding library code on rPi to decode just about any resolution since rPi has so much RAM (and can drive bigger rgbpanels). It's super cool that this library was written in a way (with callbacks) that porting it to ESP32 SPIFFS/FatFS, and then straight linux (rPI) was very little work. Here's the result: https://youtu.be/bQc7sh-a6hQ?t=163

Ideally in my "copious spare time", I should sync up my old fork against this one, but given that the old one is working fine for me, it's not been pressing on my list of priorities ;) https://github.com/marcmerlin/AnimatedGIFs most of my relevant code is here https://github.com/marcmerlin/AnimatedGIFs/blob/master/GifAnim_Impl.h

That said, I see that this lib has changed "a lot" since the fork I made, so it'll likely be a new port as opposed to a resync