From: Club Neon <clubneon@hereintown.net>
  To  : ggi-develop@eskimo.com
  Date: Thu, 1 Jul 1999 22:15:45 -0400

Re: Got to be a faster way.

> Never use PutPixel or MapColor in a loop processing an entire screen.
> No implementation in the world is ever going to change that making
> one or more function calls per pixel is going to be dog-slow.
>
> > Page flipping really isn't an option, as I want one set of
> > routines that will work on all targets.
>
> Why? There is no reason to waste user's resources by deliberately
> writing non-optimal code. Use whatever features you can take advantage
> of when they are present, and provide well written fallbacks when they
> are not.

I was under the impression this was a "General Graphics" libary.  So there
are plenty of really nice funtions, where I can just write one routine to
handle any graphics mode and bit depth.  I don't have to worry about
palletes or the layout frame buffer.  But I can't use any of them if I
expect to do any real work.  Instead I must fall back to old DOS techniques
of trying to guess what hardware, er, um, target I'm working on, and then
directly manipulate it as best I can from the security confines of Linux.
Doesn't that sound "non-optimal"?

> There is no such thing as a "ggipixel". ggi_pixel is just a datatype
> corresponding to an unsigned integer, large enough to hold the largest
> possible pixelvalue.

Sorry, I forgot an underscore.  As I said, I've been doing this for 2 days.
I don't have all the cases/underscores memorized yet.  I just keep `less
ggi.h` running on the second virtual terminal when I'm venturing into new
functions/data types.

> The correct way to put pre-rendered images to the screen when not using
> DirectBuffer is ggiPutBox(), or if it makes things much simpler
> - ggiPutHLine().

As I was venting above about.  So I have to Put a Box from a buffer that
there are no real functions to manipulate?  Wouldn't it make sense, that if
the only real way of getting speed from this lib is to use the Put
functions, to include fast functions for setting up, and making sure the
data is in the right format for, these buffers?

Sorry for being a little flippant, but this flippant reply to me, just set
the mode.  libGGI presents some good ideas on the surface, though I was just
a little disheartened when I scratched through the veneer to find I have to
rely on the same old device dependent routines.  I will continue to use
libGGI, I'll probally even end up writing
page-flipping-or-if-that-doesn't-work-ggiPutBox-buffer-manipulating-routines
.

Oh well,
Chris