nanogui: Thread: GrArea extensions - some coded and more info

Morten,
    After going ahead and coding up an enhanced GrArea
as described in my last email, I realized a little more what
you were talking about, and also realized that some of the
proposed solution didn't really solve your problem.  This
email attempts to describe what I've done.

GrArea now takes a void *pixels and int pixtype
parameters.  The pixtype parameter describes not only
the type of pixel data, but it's array packing structure as
well.  Following are the types implemented:

pixtype                            array of
PF_RGB                         COLORVAL (unsigned long)
PF_PIXELVAL              PIXELVAL (compile-time dependent)
PF_PALETTE                 unsigned char
PF_TRUECOLOR888    packed struct {char r,char g,char b} (24 bits)
PF_TRUECOLOR565    unsigned short
PF_TRUECOLOR332    unsigned char

Two new pseudo pixel formats are used, (PF_RGB and
PF_PIXELVAL)  these values are never returned by display 
drivers, but used to describe the pixel data following GrArea.

Thus, to draw an area composed of an array of 32-bit COLORVAL
RGB values, use PF_RGB. In this case, the server translates all RGB
values to PIXELVALs.  If the array is built from an array
of PIXELVAL sized (unsigned long) pixels, then specify PF_PIXELVAL.
In this case, no translation is performed by the server, but the
data is still packed in unsigned longs (unless the PIXELVAL
typedef is changed).  

The other PF_ values are used to specify a different packing order
for the pixel data.  For instance, if the server is running in 
PF_TRUECOLOR565 mode, then an application can send
pixels in an unsigned short array of 5/6/5 values, and the server
will unpack it, NOT translate it, and display it. 

Currently, the server doesn't translate any pixel values, except,
of course, PF_RGB.  It would be fairly easy, and slower than
it already is, to translate any of the truecolor values, providing
the system was already running in some truecolor mode.  I
leave that as an excersise for anyone who desires it.  The server
still doesn't use bitblit to output pixelvals, this is a subject
for another discussion, as there are byte alignment issues.

A note on translation costs:  currently, the system runs
slowly when having to translate RGB values.  It attempts
to scan-line optimize drawing of the same color, but that's
it.  Even with PF_PIXELVAL output, which can always
be sent unmodifed to the display, we don't yet use blitting.
Blitting will require that the data be linelength DWORD-aligned
so that fast memcpy routines can be used.  I am convinced
that server translation will result in unacceptable image
display speed.  This means that your desire of writing
an application using any pixel format, and having the
server translate it will almost likely result in poor 
performance.

In Microwindows, I use a PIMAGEHDR structure
that carries an RGB table.  The system builds a one-time
COLORVAL to PIXELVAL conversion table
that allows the image to be redisplayed extremely
quickly after calculating the conversion once.  GrArea
doesn't use this idea.

So, this design allows for pixel translation extensions,
if really desired, as well as RGB standard images.  It
also allows an application to be coded in the pixel
format that the server is running, if desired for speed
and/or convenience.  What remains to be done is to 
use fast blitting to get the pixel data to the display.
This will work only when the pixel packing is the
same as the display type.

This code will be available in 0.87pre3 on Sunday
evening.

Regards,

Greg