A BBN colleague, Ray Tomlinson, noted:
------------------------------------------------------------------------
I am displaying on a truecolor visual using Exceed under Windows NT. The
problem is that a number of the colors are wrong.
The problem also manifests itself when displaying Linux output on an SGI
box having a truecolor visual. This eliminates any server peculiarities.
The problem is that all images have no red in any of their colors. Only
images are affected; lines, polygons, etc. are ok.
The problem appears in three different versions of jdk for Linux:
jdk1.1.5v5 jdk1.1.5v7 jdk1.1.6v1.0
The first two are ports done by Steve Byrne. The third was done by Sergey
Nikitin at ASU. They probably are both using the same buggy code.
I can eliminate the problem by unchecking the "use 32-bit pixels
for truecolor" option in the protocol configuration of Exceed. It
is reflected as exactly one change in xdpyinfo output:
number of supported pixmap formats: 2
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 16
depth 24, bits_per_pixel 24, scanline_pad 32
versus
number of supported pixmap formats: 2
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 16
depth 24, bits_per_pixel 32, scanline_pad 32
------------------------------------------------------------------------
If I recall correctly, 32-bit color is [Red][Green][Blue][Alpha]. If
some layer were confused and just masked off the lower 24-bits, you'd
lose [Red]. Switching to 24-bit color would make the problem appear
to go away.
Maybe this is the problem:
* comp.os.linux.development.apps, 27 Mar 1998
"Arcadio A. Sincero Jr." <[EMAIL PROTECTED]>
The problem is that the colors for the image are all wrong! All the
blues look like green. In fact, everything but black in the image is a
shade of green (grays look blue green, whites look light green, etc.).
* comp.os.linux.development.apps, 27 Mar 1998, [EMAIL PROTECTED]
I believe I've since narrowed the problem down to the X server. The
X server I'm using isn't a Linux X server. It's a Windows X server
(eXceed). And it seems that there's bug in my version in that it's
not reporting the correct color depth. 'xdpyinfo' and 'xwininfo
-root' both say that the color depth is 24bpp, with a visual class
of TrueColor. Even when I tell eXceed to use 'PseudoColor',
'xdpyinfo' still says it's a TrueColor display.
Or, is it an endian problem of some sort? Perhaps a conversion
to/from network order is being done in one place but not another.
Notice what this guy says about RGB coming out BGR:
* comp.os.linux.development.apps 16 Apr 1998
[EMAIL PROTECTED] (Jan Hubicka)
I am playig with truecolor support in XaoS. XaoS uses his own routines
to convert pixel to rgb and back to make it faster (the X ones are slow).
It supports standard truecolor (r<<16)|(g<<8)|b, wich work well at
most PC I expect. Some computers have reversed endianity, so XaoS
support this too (b<<24)| etc... It works for example at BeOS.
Problem happends here with UltraSparc. It uses same format as PC
(in reversed enddianity) so (r<<16)|(g<<8)|b works w/o problems in
kernel code or so. But inder X it for some strange purpose seems
to use red at blue place and opossite. Green is at place.
Geoffrey
--
Geoffrey S. Knauth http://world.std.com/~gsk
