Subject:
Re: Can we make PIXELVAL a 16-bit entity?
From:
Morten Rolland ####@####.####
Date:
10 Dec 1999 11:38:51 -0000
Message-Id: <3850F295.BAF71E2C@screenmedia.no>
Hello!
Greg Haerr wrote:
> First - no this definitely doesn't run counter to my design philosophy;
Thats what I thought, just wanted to check, thanx.
> My original design idea was that the entire graphics computing
> system could "inherit" characteristics of the lower level hardware
> and use that for most effecient processing and memory use,
> considering that's the point of this project, really.
I guess you mean "inherit" WRT compiling an entire system with
same setup for both servers, libraries and user apps, right?
Adjusting the PIXELVAL or packing method should be done globally
to get the best results (so they match each other all the way).
> So - I had previously considered that sizeof PIXELVAL would be
> either only 8 or 32, but 16 is just fine. What I'd like to see
> would be minimal #ifdef's throughout the shared code,
> if possible; perhaps separate procedures for packing/unpacking PIXELVALs
> into ReadArea buffers, with an upper level #define for which procedure
> to call. This keeps the main code extremely easy to read and understand,
> which is another goal of mine for this project.
Yes I agree that separate functions are a clean solution. If you have
looked into GGI you will know that they do this, only to the
extreme; they use dynamic run time loading of shared libraries to match
up against the hardware/target with optimized functions, but with no
calling overhead. We don't need this to the same extent, as we only
compile for a single target at a time (I guess...)
> Now - there's one more consideration, and that is that when running
> client/server, we need to tell the server which algorithm to use
> as well, since it may not be running the same hardware. [I think
> we can assume that it always will, but just in case].
OK, this is my take on this that I have started to code (for Nano-X):
The GrArea call in 'client.c' uses GrNumArea=40 IIRC and a struct with
the area-info and a bunch of pixles trailing it.
I figured one could solve the problem in a simple manner by introducing
a new protocol "opcode" GrNumArea_R5G6B5=47 that uses the same struct as
the original GrArea, but with 16 bit pixels trailing it. This reduces
the memory usage and transfer time. The pixels needs to be formatted
at the client to use the 16 bit encoding that this particular version
of the GrArea call supports, but this is the general idea like you
stated earlier.
If the Nano-X server happens to have 8, 24 or 32 bits/pixel, the 16 bit
values supplied with this call can still be converted and displayed.
I would like this to be optional though, to save space when you don't
need it. Likewize, I'd like to be able to selectively decide which
GrArea_* functions I want in my library so that a 16 bit only setup can
have as small code footprint as possible.
As to the entery point in the Nano-X client library, it could be done
like:
#define NANOX_PF PF_TRUECOLOR565
#include <mwin/nano-X.h>
...
PIXELVAL *p; /* sizeof(*p) == 2 */
...
GrArea(id,gc,x,y,w,h,p)
/* Gets expanded to GrArea_R5G6B5(id,...) by a #define in
* nano-X.h depending on the value of NANOX_PF
*/
The NANOX_PF could default to 24 bit colour, to make life easier.
Also, when doing this, the RGB macro or some similar macro should
be defined according to the pixel format used, but I'm not quite
sure if RGB() is the right macro for this: Judging from the
definition of RGB(r,g,b) it returns a COLORVAL value, which is used
for a couple of things; but is it intended to be used to build
PIXELVALs for GrArea as well?
If not, a macro 'RGB2PIXEL(r,g,b)' could be used to do this, along
with 'PIXEL2GREEN(PIXELVAL c)' etc. To manipulate the PIXELVAL
'images'. Applications like MPEG players would like to avoid using
macros and instead do their own lookups etc. for speed, while some
applications like our own, would use precompiled binary files
in 565 format for buttons etc.
> Go ahead and do it, send me the mods. Use 0.87pre1 as the
> base. Like I said above, keep it simple if possible.
OK. There are som issues with optimizing at the device independent
drawing code/device drawing code, but I'll leave that alone at the
moment.
- Morten
