[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: More on 16-bit color, and more
From: Greg Haerr ####@####.#### Date: 4 Jan 2000 17:46:14 -0000 Message-Id: <C1962B36D9BBD311B0F80060083DFEFBEFF4@NBA-SLAM.CenSoft.COM> : In device.h a simple test for __PIXEL16__ selects 16-bit PIXELVAL : if defined. This is fine, but I like your SCREEN_PIXTYPE idea below better. : : 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? I applied this patch when you first sent it long ago, figuring you were correct that (void *)++ doesn't always increment by 1. : : As to how microwin should be updated to support different PIXELVAL : sizes, I have the following suggestion: : : #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? Sure, go ahead. I like it. Since PIXELVAL needs to be defined early on, you might want two separate sections in device.h for the #if testing, so that all the RGB color stuff doesn't get dragged to the top of the file... I try to keep the type declarations ahead of all the macros. Regards, Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: More on 16-bit color, and more
From: Morten Rolland ####@####.#### Date: 5 Jan 2000 13:50:22 -0000 Message-Id: <38735726.606A01D6@screenmedia.no> Greg Haerr wrote: > > : In device.h a simple test for __PIXEL16__ selects 16-bit PIXELVAL > : if defined. > > This is fine, but I like your SCREEN_PIXTYPE idea below better. So do I - my patches was really what I (thought...:-) I had to do to make it run and demonstrate 16-bit colors, and nothing more. Should have stated that better. > : As to how microwin should be updated to support different PIXELVAL > : sizes, I have the following suggestion: [deleted] > : I can write the patch itself if you think this is a good idea? > > Sure, go ahead. I like it. Since PIXELVAL needs to be defined > early on, you might want two separate sections in device.h > for the #if testing, so that all the RGB color stuff doesn't get > dragged to the top of the file... I try to keep the type declarations > ahead of all the macros. OK, will try. 'Guess you want patches against pre3? - Morten | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: More on 16-bit color, and more
From: Greg Haerr ####@####.#### Date: 5 Jan 2000 17:26:23 -0000 Message-Id: <C1962B36D9BBD311B0F80060083DFEFBF16B@NBA-SLAM.CenSoft.COM> : OK, will try. 'Guess you want patches against pre3? Pre3 would be great | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |