From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Sat, 03 Jul 1999 11:41:57 +0000

Re: Got to be a faster way.

Club Neon wrote:
> > If that doesn't work, as you are using a palettized visual, you will very
> > probably want to set up the palette in a way that allows to calculate the
> > palette entry from the pixelvalues. Everything else is slow.
> 
> How is the pallete set with ggiSetColorfulPallete?  Is it a full 3-2-3 bit
> distribution?  Or something else?

That is undefined. It is only guaranteed to be colorful. ;)

> With the pallete with set with 3 red, 2 green, and 3 blue (or some similar
> configuration (I might weight green heavier as the human eye is more
> sensitive to green)) and then set the pallete in order like:
> 
> 000-00-000
> 000-00-001
> ...
> 111-11-110
> 111-11-111
> 
> So black is pal[0], white is pal[255], and all other colors are between
> starting with the blues.  That way the byte value of low-order truncated
> color is also the pallete enty.  Is that what you ment?

Yes. By setting the palette in this way you in effect get a 8 bit
truecolor
visual.

> Okay, now that I have done a little math to put things into perspective in
> my head.  I'll stop complaining about pixel oriented opertions being too
> slow.  On a 133 Mhz processor like mine, at 320x200 with 15fps (really low
> end), requires almost a million pixels to be processed a second.  So that
> only gives 133 clock ticks per pixel, can't do much with that even in
> assembly.

Especially not on Intel crap, where minimum overhead for making a
function
call is ~17 cycles (if everything is in the L1 cache), compared to real
processors where it's one cycle.

> Should I use ggiPutHline or ggiPutBox?  I'm redrawing the whole screen
> everytime (as the few times I don't are so rare that testing for them, would
> probally cost more time than saved when they happen).

ggiPutBox is slightly faster due to less overhead, while ggiPutHLine
requires less memory. If you want to be optimal you can use HLine for
high resolutions and Box for low resolutions. Otherwise just pick the
one you like best.

> > Of course if you use a palettized visual, this will always be slow, as the
> > color matching is an expensive operation. Setting a palette with an
> indexing
> > the can be calculated from the RGB values helps there.
> 
> Like I was saying above?

Yep.

> > Well - a memory visual is a fully fledged visual where you can use and
> > LibGGI function on. A GetPut buffer is just raw memory. Querying the
> > structure is done using ggi_pixelformat *ggiGetPixelFormat(ggi_visual_t
> vis);
> > for pixelbuffers (get/putbuffers), while you use ggiDBGetBuffer for
> > a visual.
> 
> Sorry, I don't follow.  Lets just forget about the format of the visual,
> lets just concentrate on the pixel buffer.  Or do I need to worry about the
> format if I use ggiPackColors?  

ggiPackColors produce pixels on a format suitable for Get/Put buffers.

> Basicly what I'm asking, in an 8 bit
> palleted mode, will I find 1 byte per pixel that is the pallete entry?  For
> say a 24 bit mode, will I find 3 bytes per pixel?

Yes.

There is one 'but' though. On 24 bit modes the length of each line
in a ggiPutBox/ggiGetBox buffer is rounded up to a multiple of 4
bytes. However, as long as your width in _pixels_ is a multiple of
4 you don't have to worry about this.

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