nanogui: More on 16-bit color, and more


Previous by date: 4 Jan 2000 13:18:07 -0000 Re: Help. - Microwindows porting on ARM, Alex Holden
Next by date: 4 Jan 2000 13:18:07 -0000 Fonts and keyboard support, Vidar Hokstad
Previous in thread:
Next in thread: 4 Jan 2000 13:18:07 -0000 Re: More on 16-bit color, and more, Greg Haerr

Subject: More on 16-bit color, and more
From: Morten Rolland ####@####.####
Date: 4 Jan 2000 13:18:07 -0000
Message-Id: <3871FE0B.DA1F8CBC@screenmedia.no>

Happy new year everyone!

I have had some time to try out 16-bit colors on nano-X, and I must
say it works very well!  It seems to work flawlessly on both /dev/fb
and X11 when using standard 565 encoding of the pixels.  Although
the X11 version is rather slow on large images, but this can be a
bonus when debugging!! :-)

In order to get it to work, a few patches was applied, explanations
at the end:

Index: engine/devdraw.c
===================================================================
RCS file: /sw/CVSROOT/freepad/microwin/src/engine/devdraw.c,v
retrieving revision 1.1.1.1
diff -u -4 -r1.1.1.1 devdraw.c
--- engine/devdraw.c    1999/12/20 09:19:14     1.1.1.1
+++ engine/devdraw.c    2000/01/04 12:27:24
@@ -1296,9 +1296,9 @@
                /*
                 * For size considerations, there's no low-level area
                 * draw, so we've got to draw everything with per-point
                 * clipping for the time being
-               if(pixtype != PF_PIXELVAL)
+               if(pixtype != PF_PIXELVAL && pixtype != PF_TRUECOLOR565)
                        break;
                psd->DrawArea(psd, x, y, width, height, pixels);
                GdFixCursor();
                return;
Index: include/device.h
===================================================================
RCS file: /sw/CVSROOT/freepad/microwin/src/include/device.h,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -4 -r1.1.1.1 -r1.2
--- include/device.h    1999/12/20 09:19:13     1.1.1.1
+++ include/device.h    2000/01/03 10:45:39     1.2
@@ -39,9 +39,13 @@
 #ifdef __AS386_16__
 /* support up to 32 bit truecolor except on ELKS for size*/
 typedef unsigned char  PIXELVAL;       /* pixel color value*/
 #else
+#ifdef __PIXEL16__
+typedef unsigned short PIXELVAL;       /* 16bpp pixel color value */
+#else
 typedef unsigned long  PIXELVAL;       /* pixel color value*/
+#endif
 #endif
 typedef unsigned int   BUTTON;         /* mouse button mask*/
 typedef unsigned int   MODIFIER;       /* keyboard modifier mask
(CTRL/SHIFT)*/ typedef int            FONTID;         /* font number,
0=default font*/
Index: nanox/client.c
===================================================================
RCS file: /sw/CVSROOT/freepad/microwin/src/nanox/client.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -4 -r1.1.1.1 -r1.2
--- nanox/client.c      1999/12/20 09:19:14     1.1.1.1
+++ nanox/client.c      2000/01/03 10:45:39     1.2
@@ -967,9 +967,9 @@
                req->width = width;
                req->height = chunk_y;
                req->pixtype = pixtype;
                memmove(GetReqData(req), pixels, size);
-               pixels += size;
+               pixels = (void *)(((char *)pixels) + size);
                y += chunk_y;
                height -= chunk_y;
        }
 }

The first patch to devdraw.c is a hack; it made it possible to use
PF_TRUECOLOR565 on the client side, which should work when the server
usese the same format natively.  This test should really look quite
different and be dependent on the SCREEN_PIXTYPE macro instead (nanox
server compile time option), but I have not tested this.

In device.h a simple test for __PIXEL16__ selects 16-bit PIXELVAL
if defined.

The last patch to nanox/client.c is a portability issue as I have
mentioned before.  If someone knows what ANSI-C/standard-C has to
say about sizeof(*(void *)) WRT pointer arithmetic, I'm all ears;
my impression is that GNU-C has made its own standard in this
respect that may not port well?

As to how microwin should be updated to support different PIXELVAL
sizes, I have the following suggestion:

Use the SCREEN_PIXTYPE macro to decide what the environment is like.
It can be done like:

#ifndef SCREEN_PIXTYPE
#define SCREEN_PIXTYPE PF_PALETTE
#endif

#define PF_RGB          0       /* pseudo, convert from packed 32 bit RGB*/
#define PF_PIXELVAL     1       /* pseudo, no convert from packed PIXELVAL*/
#define PF_PALETTE      2       /* pixel is packed 8 bits 1, 4 or 8 pal
index*/
#define PF_TRUECOLOR888 3       /* pixel is packed 24 bits 8/8/8 truecolor*/
#define PF_TRUECOLOR565 4       /* pixel is packed 16 bits 5/6/5 truecolor*/
#define PF_TRUECOLOR332 5       /* pixel is packed 8 bits 3/3/2 truecolor*/

#define RGB2PIXEL24(r,g,b) ...
#define ...

#if SCREEN_PIXTYPE == PF_TRUECOLOR24
typedef unsigned long PIXELVAL;
#define RGB2PIXEL(r,g,b) RGB2PIXEL24(r,g,b)
#define PIXEL2RGB ...
#endif

#if SCREEN_PIXTYPE == PF_TRUECOLOR565
typedef unsigned short PIXELVAL;
#define RGB2PIXEL(r,g,b) RGB2PIXEL565(r,g,b)
#define PIXEL2RGB ...
#endif

etc.

This will separate the various modes into nice sections that should be
easily maintainable and understandable.  They can also be easilly
extended by adding new sections.  Testing for various other build
targets can be done at the beginning of the file; e.g. forcing
SCREEN_PIXTYPE to PF_PALETTE if __AS386_16__ is defined.

The test in GrArea for pixtype support can be a test against
SCREEN_PIXTYPE.

I can write the patch itself if you think this is a good idea?

Regards,
Morten Rolland, Screen Media

Previous by date: 4 Jan 2000 13:18:07 -0000 Re: Help. - Microwindows porting on ARM, Alex Holden
Next by date: 4 Jan 2000 13:18:07 -0000 Fonts and keyboard support, Vidar Hokstad
Previous in thread:
Next in thread: 4 Jan 2000 13:18:07 -0000 Re: More on 16-bit color, and more, Greg Haerr


Powered by ezmlm-browse 0.20.