nanogui: Can we make PIXELVAL a 16-bit entity?


Previous by date: 8 Dec 1999 18:47:14 -0000 Can we make PIXELVAL a 16-bit entity?, Morten Rolland
Next by date: 8 Dec 1999 18:47:14 -0000 Re: fonts in nanox, Chris Ross
Previous in thread: 8 Dec 1999 18:47:14 -0000 Can we make PIXELVAL a 16-bit entity?, Morten Rolland
Next in thread: 8 Dec 1999 18:47:14 -0000 Re: Can we make PIXELVAL a 16-bit entity?, Morten Rolland

Subject: RE: Can we make PIXELVAL a 16-bit entity?
From: Greg Haerr ####@####.####
Date: 8 Dec 1999 18:47:14 -0000
Message-Id: <796896539E6CD311B0E70060083DFEFB0772CC@NBA-SLAM.CenSoft.COM>

: First off, the X11 stuff in 0.87pre1 works ok and is of great help
: for testing!  As for speed, it seems much better, but we have not
: tested extensively yet, e.g. Opera.

Great.  Keep me posted on the speed stuff with Opera, when
your team finds the time.  It's very important to me that
both Nano-X and Microwindows can blaze...


: 
: I've got a question: We will use a 16 bit display, and would like
: to use GrArea/GrReadArea to draw nice widgets and stuff.  If we
: included code to make PIXELVAL only 16 bits, would this require
: extensive rewrites of mwin/nanox?  And more important: Would it
: run counter to design philosophy?

First - no this definitely doesn't run counter to my design philosophy;
in fact, if you check out device.h, you'll see that there's already an
#ifdef for the ELKS systems that will never use PIXELVALs larger
than a byte, and it'd be a shame to require 32bpp images when
only 8bpp are required on 16 bit systems. 

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.

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.

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].



: 
: I think it should work well, but I'd like to get a GA on this
: before changing too much...
: 
: Should I/we try this?
: 

Go ahead and do it, send me the mods.  Use 0.87pre1 as the
base.  Like I said above, keep it simple if possible.  You'll see
that this is already an item in the TODO list...

Greg


Previous by date: 8 Dec 1999 18:47:14 -0000 Can we make PIXELVAL a 16-bit entity?, Morten Rolland
Next by date: 8 Dec 1999 18:47:14 -0000 Re: fonts in nanox, Chris Ross
Previous in thread: 8 Dec 1999 18:47:14 -0000 Can we make PIXELVAL a 16-bit entity?, Morten Rolland
Next in thread: 8 Dec 1999 18:47:14 -0000 Re: Can we make PIXELVAL a 16-bit entity?, Morten Rolland


Powered by ezmlm-browse 0.20.