Give Your Next GUI Some Gloriously Smooth GIF Graphics, Thanks to BitBank's AnimatedGIF Library!

Depending on the latest digital doo-dad that you are designing, you may or may not have a GUI on your checklist of things to get done.

Sure, a simple Bluetooth sensor widget doesn't need a lot in the way of interaction, but with the ferocious amount of flippin' powerful silicon that we've seen sneaking its way into a slew of recent projects, it's safe to say that these days, be they — EPD, OLED, or TFT — displays are all the rage.

When we are blessed with such glorious, high-pixel density count displays, originally destined for some mass produced digital device, the economies of scale mean that we can too can plonk down a plate of pixels on our PCB for practically peanuts.

Indeed, we're blessed with a multitude of options, aspect ratios, shapes, interfaces and even technologies, but if you want a slick looking — by which I mean "marketing approved" — GUI, you generally need to grease things up with a bit of smooth graphical goodness.

A menu that makes smooth transitions is one thing, but sometimes you want a nice "loading screen," or some other GUI element that could do with a bit of animation.

There's a few ways to go about that also, from slicing frames manually to arrays — and struggling with the multitude of converter GitHub projects and formats, or instantiating a system of sprites and other graphical primitives, it already sounds a bit of a convoluted, grandeur effort.

It doesn't have to be, though — getting GIFs gliding like grease lightning takes little to no effort, thanks to the efforts of BitBank Software, and their release of the Arduino-approved AnimatedGIF library.

BitBank Software — known to some of us as The Performance Whisperer on Twitter — has a skill for scraping the absolute possible performance from code that most of us would just kludge together.

With a focus on optimization, he spends the bulk of his time working his magic for a number of clients that carry some mighty heavy stock prices — finessing the code he is furnished with from functional, to frictionless. This is an art that escapes a lot of us — with many of our projects perfectly able to live with the globs of glue that bind together various GitHub libraries, the work done for those Tier 1s has a direct impact on every aspect of their output — from UX to even their carbon footprint.

Thankfully, BitBank Software also see the philanthropic side of things and are no strangers to contributions and pull requests to popular libraries that many of us already could — if not, should — be using.

The latest bit of magic to make its way onto my desk is the AnimatedGIF library, which offers gloriously smooth graphics, with little to no effort — compared to some of the other yak-shaving approaches I can say I've encountered in the past!

It all starts with your graphics.

Jump on Google Image search, Giphy, or wherever, and grab what you want to have gliding across the display of your gadget.

I'm going to look to give one of my dev boards a fancy "splash screen", so while the process detailed below is going to be fine for full-screen fun, it's fully tunable to your own needs.

My media source, for reasons that are pretty obvious, is going to be this little bit of marketing, which started life as an MP4 in our cache.

I'm not going to list the many, many ways of getting from A to .GIF, but if you're handy with command line tools, ffmpeg works wonders — and a wide range of them!

My example is using the TTGO T-Display board, with a 240 x 135-pixel IPS display, and my initial source was close enough in aspect ratio such that the following one-liner worked a treat for me.

ffmpeg -i <input_file> -vf scale=240:-1 output.gif

If you don't want to get freaky with the ffmpeg command line interface — there are a number of online, graphical interface GIF editors that can get your media sized appropriately.

Now for the 'hard' bit.

To get the GIFs gliding like grease, we're going to run them through the command line tool pre-processor, image_to_c, also provided — pro-bono — by BitBank.

The pre-processor is a part of the streamlining process, pre-formatting the GIF data into an array of data that can more fluidly flow through the various functions that will feature in the process that finally throws our GIF up for us to gawk at!

But it's also much more than that. It is a very logical away to approaching the idea of embedding a file — any file, it doesn't have to be a GIF — into an array that can be easily imported into your Arduino sketch — the code itself — rather than needing to add in some external storage, such as an SD card or SPI flash.

If you've only got a few frames of GIF data, for example, you might find that the bytes generated by image_2_c can fit within the code space of nearly any modern MCU. It's something to keep in mind, in place of the de facto fix it of add on a flash chip.

There's a practical point to be made that optimization is a practice that can be implemented at any stage of a process, and much in the way that our compilers translate our C into machine code, employing such similar pre-processing as these tools into that process of pre-compilation can pay off when it comes to the final product.

For the Windows crowd — there are now 32-bit and 64-bit exe versions of image_2_c, that can be called from the command line. This should save you having to install cmake et al. — if that's not your thing.

As a side note, these exe files are the first thing I've ever contributed to a GitHub project, and I'm looking at some GUI tools for offline GIF cropping, to make this even easier. But less of that, onwards. Let's crack on with converting.

All it takes is a simple one line command, that will instruct image_to_c to create the header file that is expected by the AnimatedGIF library.

We feed our GIF file —in this case, "slide4.gif" — and use the ">" operand to direct the output of the process to a file of our own naming. I've used "slide4.h" because there's no sense in making things harder to keep track of, right?

Hey presto, almost instantly, we are presented with our hot-off-the-process header file, ready to feed into our Arduino sketch.

As we're targeting Arduino, including an additional file isn't exactly hard, yo. From the "Sketch" menu, simply click "Add File," and go find that header file we just generated.

A short folder thoroughfare later, and you should see your data presented in the IDE window, under a new tab, by the same filename.

This is the array that is our formatted, finessed GIF, ready to be read in and played out on our panel of pixels.

There are a few configuration options that you'll need to make to the sketch — there's support for a lot of options when it comes to configuring the available hardware that can host this optimized code.

I'm working with a bare example that demonstrates the capabilities of the code, so there's a little user effort required, but with a plethora of examples, and well commented documentation, it's pretty easy to get set up for your specific hardware.

The gist of the changes amount to making sure all the references to the data array are in place. Most of us can figure out from Ctrl+F on the arrays referenced in the example code, which bits we need to adjust.

We can our slide4 data haphazardly referenced in the demonstration sketch, where once was ucBadgers is now our set of slide4 references.

That first compile always seems to take a while...

It could be likened to watching paint dry, but waiting for the sequence of compilation and subsequent upload can feel like forever when we're working with fun features like these — we just want to see those graphics glide!

But, before you know it, your beautiful array of bytes is breezing by on your screen, at framerates that are simply beautiful to behold.

A few experiments along the way look almost too good to be true, for such tiny devices.

I could watch that infinity loop... well, forever.

With the TTGO T-Display being an ESP32-based board, the display library of choice is able to make use of DMA, resulting in framerates that are frankly on fire!

We all thrive from the contributions of many, many skilled and talented people who donate their time and skill to the software and hardware that we happily hack away upon.

We all understandably hand over the hard earned cash when it comes to hardware, but often, perhaps it's fair to suggest that the open source software side of things doesn't get the same love — it's perhaps harder to appreciate the value of something that you can't hold...

With BitBank Software turning out trailblazing optimizations like this, using his spare time to target his optimizations at a number of the libraries that a lot of us are likely to benefit from using, I'm just going to less than subtly suggest that along with following him on GitHub, you might find yourself subsequently sponsoring his efforts while you're there!

For this sorta blisteringly fast bundle of GIF goodness alone, I think I'm going to have to at least buy him a beer — or a box of!

But, it's more than moving images...

BitBank Software is on a quest to quell the wastage that so often goes along with code that might function for that MVP, but perhaps forgoes the finesse that can result in the reduced operating costs when a product faces the scale of volume operation.

Code that can run more efficiently results in less time with the CPU clocked up to speed, churning through redundant op-codes, and instead, more time snoozing away between operations — occasionally slamming down a shot, rather than chugging away on the keg all evening. I won't follow the analogy through to the wastage, but you can perhaps follow that it this methodology results in less... waste.

A million units wasting a few mAh due to misunderstood code can add up to a significant load — an amount of power that we could sorely do without looking source — sustainability should take precedence over slapdash if our tech is going to save the planet.

Indeed, the cornerstone of the engineering philosophy is the optimal, most efficient approach and with thanks to the philanthropism of contributions from coders such as BitBank, this is an approach that is becoming more available to all of us who build upon the incredible contributions to the open source world.

It's a worthy cause that stands to benefit all of us —not just for great graphics, but the greater good.