KNOWN ISSUES

##############################################################################

Loading very large images can crash if your system does not have enough RAM.
This is something you need to keep in mind before loading giant pictures.

##############################################################################

blit_transform - flip_horizontal - has known issues.  It only happens with
some images.  I am not yet sure what the issue is.  Try instead rotating
180 degrees and then flip_vertical, if you have issues.

There may be other flipping issues, but this one is the most obvious.

##############################################################################

UNMASK drawing for 16 bit displays may have issues.  Use MASK mode in
reverse as an alternate workaround.

##############################################################################

I re-enabled the console status methods, but for some reason, they are not
very reliable.  They simply read "/sys/class/tty/tty0/active" to determine
which console they are running inside, and if it's different than the console
at initialization, it is supposed to wait.  Something in that process is
flakey.

##############################################################################

Some framebuffer drivers are tearfully slow (not many).  I have noticed that
the Nouveau framebuffer driver for NVidia is Molasses slow.  It's amazing how
slow it is.  Other framebuffer drivers are amazingly fast.  It's clear the
Nouveau framebuffer driver is in dire need of optimization, or at the very
least hardware accelerated buffer copy, like CPU DMA.  I'll be looking into
finding ways to overcome this issue.

After more testing, it seems non-bulk read or write access is simply very
slow.  Odd really.  Operations in normal mode, like blit_write are very
fast, but any other mode like OR or Alpha, are molasses slow.  Normal mode
only writes as a large block of data, and takes no care about what it
replaces.  However, other modes require bytes, words, or long words to be read
in, processed, then written back out.  That is what is not optimized in the
Nouveau driver.  Other drivers do this quickly, even the Intel driver.  I am
assuming the other drivers use a DMA routine to transfer the memory address
framebuffer to the real framebuffer, or map the actual framebuffer to real
memory, although I suspect most do it via DMA transfers.

##############################################################################

Mouse methods are rudimentary and your user must be a member of the "input"
group for them to work.  Frankly, I recommend using your own routines with
threads, or better yet, if you really need a mouse, then maybe X-Windows and
and SDL may be better for you.
