Subject:
RE: Can we make PIXELVAL a 16-bit entity?
From:
Greg Haerr ####@####.####
Date:
13 Dec 1999 18:36:24 -0000
Message-Id: <796896539E6CD311B0E70060083DFEFB07763D@NBA-SLAM.CenSoft.COM>
: 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.
That was the whole idea behind using RGB on clients. The clients
are compiled once, and run on any server, truecolor and palettized.
The apps are written in a standard color model and will guarantee
be runnable on any server.
What you are saying is that you want an additional, non-RGB
format, that also is client-portable, but is closer to the hardware,
so that it's faster. Because of this, the client has to include
alot more code, since it needs to be able to run on palettized
systems also, not just fast 16bpp truecolor. I think that
having a mechanism to allow a client to know about the
hardware color format and run quickly is a good idea,
but having two supposedly client-portable formats is
probably a bad idea, considering this is supposed to be a small
project.
However, I don't think this is the whole problem. The
real issue is that GrArea() only takes PIXELVALs, and I
don't like the idea that portable programs should have to know
about the hardware color format. (yes, in your case, they might
want to, but don't have to). Now, the Nano-X GrArea() is a
holdover from the original mini-X api, and wasn't modified
when I added full truecolor and pseudocolor support for the
project. It's original use was just to allow a client
to copy screen areas by calling GrReadArea, and then
GrArea().
I propose that the first solution be that GrAreaXXX() be allowed
to be passed COLORVALs, so that small images, and most
drawing be allowed to be standardized, and passed as RGB.
In this way, any image can be displayed in a standard
format from Nano-X on any server.
In addition, we implement 3 more GrAreaXXX's, one for 8, 16,
and 32bpp PIXELVAL sizes. These additional
opcodes can be used, _only_ if the SCREENINFO indicates
that the hardware supports it. [I still don't see the reasoning
behind the need for multiple 16bpp GrArea's. Since the
server doesn't modify the data, can you please be more
explicit as to the need?]
[Also, we don't want to query
the opcodes, since, with the new client/server rewrite,
almost all opcodes return void, so that they can be buffered
and not have to wait for a return value]
: > 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.
Like I mentioned above, we definitely want to use SCREENINFO
for this, and not change the type of server procedure to return
something other than void.
:
: 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.
Certainly. The optimized routines are called GdBitBlt(), which
was written for very high speed. GrArea was a holdover,
and almost tries to do the same thing, except it doesn't
support offscreen drawables. (Nano-X doesn't support offscreen
drawing yet, I was planning on adding all this later)
What did you think about my previous email? The one that
described the proposed client macros?
Regards,
Greg
