Welcome to AnimatedGIF Discussions!

[bitbank2]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[bitbank2]

I created this library to allow microcontrollers with limited memory to be able to decode GIF images and animations. The 'standard' libgif assumes that you have a full framebuffer to received the images while my code tries to feed it line by line to reduce the resources needed. This also has the benefit of increasing the rendering speed to SPI LCDs if you can use DMA to transmit the pixels (decoding can occur while the previous line is sent to the display). A while ago I decided to start adding 'big PC' features to my library because there's no reason why the same code can't serve for small and big systems. Many years ago I experimented with an even faster way to decode LZW streams by using the output image as the dictionary. It requires more memory, but can be tremendously faster. This weekend I decided to add this code to the library. Feel free to comment on these ideas or anything else that would benefit the users of AnimatedGIF.

[bitbank2]

I spent a good amount of time optimizing the code with the help of the Xcode profiler. Here's the latest profile running an 8-frame 160x120 animation 10,000 times on my MacBook Air M1.

Trying to reduce the memory footprint slows things down, so it's only for systems with enough RAM. An example scenario is decoding a 320x240 image on an ESP32 to be written to a SPI LCD. In this case, the code needs about 54K + framesize = ~130K of RAM.