Subject:
Re: Can we make PIXELVAL a 16-bit entity?
From:
"Greg Haerr" ####@####.####
Date:
10 Dec 1999 18:19:52 -0000
Message-Id: <007801bf4329$6db28780$15320cd0@gregh>
: 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).
Yep
: 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.
Well, if you agree that we should inherit PIXELVAL for the entire
system, then a new opcode isn't needed, since PIXELVAL will
be assumed to be 16 bits for all pieces of the software. Only
in the case where the client wants to send different coded
PIXELVALs is this an issue. IMHO, if the client is going to
send differently coded color values, then they should be sent
RGB, since we already have conversion code for those cases.
So perhaps, with a PIXELVAL set to unsigned short for you,
this entire problem goes away. More on this below.
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,
Even if you decide that you need the separate opcodes, there's
no need for a GrNumArea_RGB565 (note the name matches
the PF_XXX naming). This is because the GdArea() server
function doesn't actually do anything with the data. Also,
if you want the server to muck with the values passed (say in the
case that you're passing truecolor 565 but the hardware
is running palette mode), then you'd be better off to get the
system palette and convert them yourself once before ever
sending them, as it would be very much faster too.
:
: 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.
I agree, but this still means that the engine has to get into the business
of PIXELVAL->PIXELVAL conversion, which I don't think
is a good idea.
I think I just realized what the real issue is. GrArea() only takes
PIXELVALs, not COLORVALs. This is because, originally, the
only purpose of GrArea was to display screen contents that were
previously read by GrReadArea(). But you're using GrArea
to display images. Now, normally, the Microwindows design
is to use RGB only for color display, since it's portable. But,
for speed, I agree we need a mechanism to be able to pass
pre-computed PIXELVALs directly to the screen for higher
speed applications. But the size of PIXELVALs is always
a constant for a particular system. So, rather than sending
differently sized PIXELVALs across and reinterpreting
them (kindof like our RGB interpretations - slow), we
need a way for the client to build PIXELVALs, and
then a single GrArea will still work.
So, the GrGetScreenInfo call will return the PF_ mode
in the pixtype member. The client can use sizeof(PIXELVAL)
to compile in the proper conversion functions. I suggest that
a small set of client-side functions be created, along with
some macros like you suggest below, that allow PIXELVALs
to be created on the client side, and then leave the GrArea
stuff as is, with the exception that of course an unsigned short
PIXELVAL be creatable at compiletime through some define.
: 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
: */
:
Morten - this is quite cool and tricky, but we probably don't need
to use it.
: 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,
Yes, I like that. According to the sizeof(PIXELVAL) in
device.h, it could export some defines that are useful to the
client programmer.
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?
Thats right, the RGB macro is not the one, it's only used to build
COLO:RVALs.
:
: 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.
Yes. This is the set of client-side library code that could be included
in the client library, and unused if not linked in. Or better yet,
be macros.
: 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.
So, we don't really need to change any devdraw.c code, since it's just
going to copy this stuff out quickly, right?
Go ahead an modify the device.h stuff and add macros there, though.
I hope my comments haven't changed your design too much, but after
thinking about it, it seems that if we inherit PIXELVAL from the server
to the client, then there's a much simpler solution than both of us
were initially thinking...
Regards,
Greg
