nanogui: client/server nano-x howto ??
Subject:
Re: [nanogui] client/server nano-x howto ??
From:
aLUNZ ####@####.####
Date:
19 Jul 2007 00:27:00 +0100
Message-Id: <469EA172.2020401@tpg.com.au>
> Just where to define the NX_FORCE_BYTE_ORDERING which is referenced in
> #ifdef. And what is the effect of defining it on a little-endian
> target and on a big-endian target?
> I'll try to test it as soon as possible, just the problem is that the
> hardware maybe no longer available very soon!!
The "NX_FORCE_BYTE_ORDERING" macro is defined in nxproto.h (just above
the definitions of the NX_WR_n and NX_RD_n macros): The purpose of the
macro is to be able to undo all the changes. i.e. If the macro is
_not_ defined then it should 'undo' all the changes that I introduced
and the code should behave as the 'native' version.
The idea behind the code changes is to make all comms between the client
and server to use network byte ordering so NX_FORCE_BYTE_ORDERING should
be defined for both client and server. However, if you know that the
client and server are going to be on the same machine and/or have the
same byte ordering then you can comment out the #define and get a slight
performance improvement. (While the compiler/linker for big-endian
targets should optimise the htonx() and ntohx() routines there is still
some overhead involved in reading/writing things like bitmaps).
Incidentally, the macros work on the presumption that native short
integers are 16 bits and longs are 32 bits in size (supported integer
types are defined in mwtypes.h). I have tried to track down _all_ int
usage and am fairly sure that that this code will run on a 64 bit
machine with appropriate definition of INTXX and UINTXX but I have not
tested this.
Also, I have just tried testing:
- Coldfire client and Coldfire server
- Linux client and Coldfire server
And everything worked equally well. However I have noticed an issue
with the screen saver, where a 'nsaver' routine will not time out (i.e.
that particular routine runs until the mouse is moved or the process is
killed). I suspect this is an issue with proc IDs not being handled
properly, but have yet to investigate fully.
At the moment it works as well as I want it to, but if anyone is
interested I might be bothered to tidy it up a bit more.
Greg Haerr - are you following this? Would this work be of
interest/value to the 'mainstream' nanogui work?
aLUNZ
