From: Club Neon <clubneon@hereintown.net>
  To  : ggi-develop@eskimo.com
  Date: Sat, 3 Jul 1999 00:44:40 -0400

Re: Got to be a faster way.

Now, that was a useful reply.  Thanks much.

> O.K. - so as I assumed you are more or less using a bgbuffer of a
> ggi_colors (not _pixels).

Oh yeah, writing e-mails from 2 different machines, neither of which are the
one I'm coding on, I got confused.  I have 1 color per pixel, that is where
the defination got blended in my head.

> O.K. - then DirectBuffer is the way to go for TrueColor targets. You query
a
> DirectBuffer structure and see if it has shift/mask entries for
> red/green/blue. If yes, the rest is pretty simple: Two nested loops going
> through the visual, doing something like
> *pixel=((bg.red>>shift.r)&mask.r) | ... green | ... blue.

Well my development machine is limited to an S3 924 VLB card.  SVGA lib
doesn't like it in true color mode, and only a few resolutions work with 16
bit color.  So I'm pretty much stuck with paletted modes on it.  I have a
test machine setup across town at a friend's house that has a nice Matrox
G200 running the matroxfb, so I can test the DB stuff there.

> You'll need three or four versions for the different pixel sizes, though.

Okay, I'll remember that.

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

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?

> If it doesn't work because the target has no DirectBuffer, you can as well
> assemble a pixelbuffer and use Putbox.
>
> The problem is, that you induce a lot of call overhead by using pixel
> oriented functions. If you have a truecolor visual, the MapColor and
> Putpixel operations are pretty much as fast as one can get them. The
problem
> is the calling overhead. Using ggiPackColors and ggiPutHline should gain
an
> order or magnitude in speed for that case.

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.

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

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

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

> Usually the format is the same for linearly encoded modes. For planar or
> otherwise weird modes Pixelbuffers are usually linearized.

At first I was using 2 dimentional arrays for all my buffers, thinking the
screen has two dimentions.  But then it hit me, if I know the width of the
screen, after that many entries into my 1 dimentional array I'm on the next
line.  Very cool, no more nested loops.  But I'm sure everyone here already
knew that.  :)  Anyway, I'm friends with linear buffers now.

Again, thanks for the informative reply, I think I've asked everything I
need to know now in this one,
Chris