From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Fri, 02 Jul 1999 22:58:54 +0000

Re: Got to be a faster way.

Club Neon wrote:
> 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.

Well, let me restate what I just said:
"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."

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

You don't "guess", and you don't have to care what hardware or target
you are working on. You only have to care about the pixel format.

> Doesn't that sound "non-optimal"?

LibGGI allows you to do things slow and easy or fast and not-as-easy-
but-still-easier-than-anything-else-which-does-the-same-thing.
If you have any ideas of how to make the easy way faster or the fast
way easier you are welcome to share them with us.

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

You are not supposed to manipulate it. The whole point is speed,
rmember?
You write the data to the buffer and then call ggiPutBox().

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

Could you please explain exactly what a function that "makes sure the
data is in the right format" does?

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

You don't _have to_, just like you don't _have to_ have virtual
memory or disk buffers in an OS - but your users will not be very
impressed if you don't.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se