KNOWN ISSUES

16 bit operations can present problems, especially with transforming images.
The "Imager" library, which this module uses for image loading, scaling,
rotating and merging, as well as TrueType rendering, only works in 24 or 32
bit modes.  All conversions have to be made to RGB565 (16 bit) within the
module in Perl code.

This makes things slower, and thus it is highly recommended you use 32 bit
mode, as that works the best, and it has more colors anyway.  True, 32 bit
mode takes up twice as much video RAM, but the trade off is worth it.

If you must use 16 bit (a TFT panel for instance), then know the following
likely do not work fast or work at all:

* TrueType Rendering * (slower)

    The 24 bit RGB888 output from Imager must be converted to RGB565 (16
    bit) before it can be displayed.  This means the larger the text, the
    longer this process takes.  You can see this behavior in the splash
    screen.

* Blit Transform *

   rotate (slower)
      Since Imager is 24/32 bit only, this rotate is done strictly in Perl
      instead, for 16 bit mode.  So thus it is slower.  The time to convert
      from 16 bit to 32 bit, rotate in Imager, then convert back takes longer
      than just rotating in Perl itself.

      Also, the 16 bit rotate code behaves a bit differently than the Imager
      rotate.  It WILL clip the corners as it rotates.  I suggest, depending
      on the angle, you have some empty space around the image before you
      rotate it.  This will compensate for the corner clipping... although...
      it will slow it down somewhat, as the larger the image, the slower it is

   scale (won't work)
      Doesn't work in 16 bit mode.  You are best off scaling images as part of
      loading them, as scaling is done while the image is still 32 bit in that
      process.  Converting from 16 bit to 32 bit, scaling, then back to 16 bit
      takes forever, and yields poor color results anyway.

   merge (won't work)
      Results may vary.  I don't recommend using it in 16 bit mode.  Imager
      merges images as if they are 32 bit images, and because it thinks the
      fourth byte is the alpha channel, it may not merge it (as mergining is
      its own alpha type process). Thus every other pixel may not look right
      for 16 bit.  I could possibly do it in Perl, but it would be a slow
      process for Perl.  You're better off using "blit_write" in the "mask"
      or "unmask" drawing mode.

* Loading Images *

When loading images in 16 bit mode, the module has to first load them, scale
them, and then finally convert them to 16 bit RGB565.  This is slower than 32
bit mode, as no conversion is needed.

When loading animated GIFs, the process is more involved, as this process is
not only multiplied by the number of frames, but also it requires merging the
frame on top of the one before it.  Here's what's happening:

    1>  Imager loads the frames
    2>  Imager converts them from 8 bit indexed color to 32 bit RGBA.
    3>  GFB goes frame by frame and does the following:

        a>  It asks Imager to scale the frame (if scaling was asked for)
        b>  It then asks Imager to merge the current frame on top of the
            previous frame, using the result of that as the current frame.
        c>  Finally, it converts the frame to 16 bit RGB565 color.  This step
            takes the longest to execute.  This step is only needed in 16 bit
            mode, and takes the longest to run.
