From: Jim Meier <fatjim@home.com>
  To  : ggi-develop@eskimo.com
  Date: Sat, 08 May 1999 14:19:27 -0600

Re: Python / GGI

"Brian S. Julin" wrote:
> 
> On Sat, 8 May 1999, Jim Meier wrote:
> > arguments and sets the default mode. Also, some functionality that I had
> > wanted is not yet there - for example, unifying the Pixel/Color types
> > and making a python type that can represent efficiently both a single
> > pixel or a block of pixels for blitting.
> 
> The color representation is the first thing I noticed when I toyed with
> writing a Perl5 extension, too.  In OO languages, the first thing you want
> to do with different the pixel formats is make a single object to represent
> them and methods to get their representation in different color
> spaces.  Since I was only toying with it and LibGGI was very new I
> decided to put it off and wait for a color/pixelformat converting
> helper-lib rather than implement YUV<->RGB and such in Perl5, since
> that should really be an optimized C routine.  I don't think we have
> anything yet to do this; closest thing is CrossBlit.
> 
> --
> Brian

I've "solved" most of the problems by saying that a ColorObject holds a
ggi_visual_t, a length, a pointer to ggi_pixel and a pointer to
ggi_color. if the visual is NULL, then it works with the color array,
otherwise it works with the pixel array. Also, In many cases I
explicitly disallow transfering a block of colors (with visual
specified) to another visual.. this is somewhat cheap hackish, but could
be fixed. I'm just trying to clean up the source..

Incidentaly, because of how ugly it is, I won't have it ready for public
consumption today. Maybe sometime tommorow. I've decided that extending
python is very fun!

Any ideas/suggestions for how you want it to work, just send 'em to me
or the mailing list, and I'll try to get them in. I'd especially like to
see ideas for large-scale operation, to make up for the speed difference
between Python and C, and to take advantage of Python's features.

-Jim.