From: Jim Meier <fatjim@home.com>
  To  : ggi-develop@eskimo.com <ggi-develop@eskimo.com>
  Date: Thu, 13 May 1999 03:26:52 -0600

Semi-Snag in PyGGI...

(PyGGI being the Python GGI module I'm debugging as we speak. Would have
been sooner, but I got some extra shifts at work)


Well, PyGGI is fairly healthy.. works quick enough for many operations,
and sure to be improved when I show you brilliant folks the source.

But in working on it, I noticed something about the ggiPut* functions
(not counting ggiPutc, of course)..

if i do (in python):
>>> for i in range(100):
... 	visual.pixel(i,0,1,1,1)  # x,y, r,g,b (in range 0..1)

I get a nice, solid white line. So far, so good. But if I do:
>>> v.hline(1, 0,100, 1,1,1)  # y, x1, x2, rgb (not the only way to use this method! :)

I get a series of dots, alternating between the color I requested and
black. I'm _Not_ using the GCSetForegound/ggiDrawHLine functions, but
building up a new color object(with associated pixel buffer) and filling
it with ggiMapColor(vis, &c) like so.. (some sanity checks removed)

p=ggiMapColor(self->vis, &c); // c being the ggi_color built correctly
from inputs
co=newColorObjectFromVisualAndSize(self->vis, (x2-x1));
for(i=0;i<(x2-x1);i++) co->pixels[i]=p;

...I've checked my code, and as far as I can tell, I'm doing the right
thing for what I understand as what must be done. But rereading the
libggi docs..


  "Get/put buffers use chunky pixels, unpacked, even if their
representation in the
  framebuffer is packed (i.e. pixel size not multiple of 8 bits) or
non-linear. Thus, the
  application does not need to know how to use planar or packed pixels
for non-direct
  acccess. "
    .
    .
    .
  "The get/put buffer passed to the LibGGI functions should be allocated
for at least width
  * height * ((ggiGetPixelFormat()->size+7)/8) bytes.

  (That is, the pixel size is obtained from ggi_pixelformat.size,
rounded to a multiple of 8
  bits (one byte), and is multiplied by the width and the height of the
buffer.)"


...Is this to say that not all pixels are actually of size
(sizeof(ggi_pixel)) ?? I had thought the pixels buffers not being packed
meant that this didn't matter... if not, could someone please show me
the proper way to fill my buffers?


PS: The reason it constructs a new colorobject/pixelbuffer is that it
always returns a colorobject containing what it drew, for convenience.



-- 
...
You know it's time to rethink your design when you can't debug your
#defines.
-Jim.