Subject:
Re: Can we make PIXELVAL a 16-bit entity?
From:
Morten Rolland ####@####.####
Date:
13 Dec 1999 11:07:32 -0000
Message-Id: <3854DFC5.C4001768@screenmedia.no>
Greg Haerr wrote:
>
> 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.
Yes, this is true. But I don't like the concept of *assuming* that
pixles are 16 bits - if they are not, we run into trouble. The
reasoning behind my design was; make it possible to make it possible
(later) to write apps and have them run everywhere, if the Nano-X
server is compiled with the proper settings, without modifying
the clients.
I like the concept of writing an app using the color scheme best
suited for the application, not the other way around. This is one
of the things I don't like with X11...
Obviously, pseudocolor will probably need special attention, but
it can be done. There will always be a system palette of sorts, and
most often it will contain some sort of rainbow we can use a lookup
table to translate into (for ugly, but working results).
But, I'm not aiming as high as it may have seemed, not initially
anyway. Se below.
> 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.
This will require more code in the client: if 16 bit; use that
for speed, else use RGB. This is the stuff that non-portable
programs are made of. NOTE: This is a statement in general
terms, my use will be fine with just about any solution.
But I'm concerned with the general usefullness if we introduce
too many hard-coded operational modes that are incompatible.
> 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.
Well, not if the server uses the same definition for PIXELVAL,
but this is a fact I don't trust, and having a Nano-X server
not being able to detect an unsupported condition is bad IMHO.
To be able to detect unsupported use, extra opcodes are
needed, and a stub function to return, or report, an error for
the unsupported function.
This also brings up another issue; optimizing. From a quick
read of the GdArea code, it seems like a good candidate for
optimizing. Depending on what the underlying hardware or
graphics API provides WRT area painting, the GdArea function
may have to have special cases depending on the features of
the underlying device drawing routines. Once you start to
optimize, merging layers of code has a very good payoff,
although it may not be as elegant. This may require different
versions of the Area code one way or another, but this is
for later study.
> : 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.
Me neither, and I would probably not code any on the conversion
code as we will not need it, but it would be a good idea to be
able to include the conversion code at a later stage to support
old applications written to run fast on 8 or 16 bit displays etc.
Allocating more opcodes is a free for all; it will not automatically
result in a bigger Nano-X server (but possibly a useless one
for certain apps, which is unavoidable anyway).
> 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.
I don't see why the PIXELVAL *has* to be the same in server
and application. In my experimental code I have typedefs for
pixelval_r8g8b8_t and pixelval_r5g6b5_t, which are used for
the standard GrArea and GrArea_R5G6B5 functions respectively
(in the client API). Depending on the NANOX_PF, the PIXELVAL
will be defined to the corresponding pixelval_*_t along with
the #define for GrArea.
My idea was to make sure the PIXELVALs are the same, and not
do any conversion (for our app) because there will not be any
code for it. But by tagging the protocol requests makes it
possible to
1) Provide "unsupported" log messages rather than
undefined behavior when mixing apps and server
with differing pixelsizes.
2) Include conversion code at a later stage if it is needed.
The conversion code should always be configurable to
save space where not needed.
> 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.
Hmm, I don't like this much. In order to make things fast,
we have to use macros, which will not adapt to a new
environment (needs recompilation to match server), or
support multiple setups in the same application.
> : 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?
If introducing new opcodes (which I think is a must), we need some
way of differentiating the various opcodes so we can reject those that
we don't support.
> 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...
I guess my problem is that I don't want the client to inherit the
PIXELVAL in order for things to work, just to work fast. But I
definitely don't want the translation code in *my* server, but that
shouldn't exclude the possibility for someone else to have it.
For this reason, I would really like GrArea_R5G6B5 to be defined to
have a solid fundament that can possibly support multiple pixel
formats (think shared library and two apps with different desires
for the pixel format).
This got way long... sorry about that.
Regards,
- Morten
