KNOWN ISSUES

#### The below only applies to systems without the Inline::C module. ####
#### If you have this module on your system, then these below aren't ####
#### 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.

   scale (tearfully slow)
      The module has to convert the image to 24 bit before scaling, then
      convert back to 16 bit. I recomment scaling while loading the image
      instead.

   merge (tearfully slow)
      Results may vary.  I don't recommend using it in 16 bit mode.  The
      module has to convert the image to 16 bit before merging, and then back
      to 16 bit when finished.

* 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.
