From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Fri, 2 Jul 1999 15:21:37 +0200

Re: Got to be a faster way.

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

You can. But of course abstraction means extra work, which will take time.

The point is, that you have the possibility to tune the balance between
abstraction and speed.

Using PackColors and PutHline should already give a major speed gain.
You can probably imagine, that no matter what tool you use, calling
two functions for about 1/2 a million times per frame (640x480)
will eat up CPU. Not matter how fast the function internals are.
If you draw whole lines at a time, you can cut that calling overhead
down by a factor of 640.

Now if you want to save the extra memory copies that are used for the
intermediate state of "ggi_pixel", you have to access the display memory.
DirectBuffer is there for this. This also allows for using optimized mapping
algorithms like using knowledge about the set palette in palettized modes.

> As I was venting above about.  So I have to Put a Box from a buffer that
> there are no real functions to manipulate? 

ggiPackColors.

> 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?

That's what either MapColor or PackColors are for. If you want to circumvent
function calling overhead, you have to read out the pixelbuffer descriptor
and write to it directly.

CU, ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =