#111 Need 32-bit Visual Support
I have managed to recreate this problem several times
using a variety of platforms.. Here's the ones in
particular:
- Debian 3 on Sparc64
- Solaris 8 and 9 on Sparc
- OpenBSD 3.1 and 3.2 on i386
Here's the problem, but it does not just occur in Exceed,
it also occurs on the local machines. I read the previous
posts targeting Exceed, but it doesn't seem to end there.
The map source GIF/JPG for Terraserver or Tigermap is
black and white (or in some elements colored).
However, something is causing the map to be converted
to a royal blue. The top layer elements are fine (tracks,
etc) but the map background object itself is dark blue.
I thought to blame Imagemagick.. But running 'display'
from Imagemagick revealed the images to be 'proper' on
screen, even in Exceed. So this could be a Pixmap
conversion problem?
Exceed is a true R6.4 (and now R6.6 in 8.0) release of
X11, everything else seems to work proper.. I have
Truecolor support enabled as well.
I'm definitely interested in fixing it one way or another,
either by finding the place choosing blue and making it
white, or by finding out where the conversion is going
wrong.
http://celeris.maine.1-x.net:8080/xastir-8.jpg gives an
example of how it looks.
Other than that, Xastir is great. :)
Versions Used to Build: Imagemagick 5.5.1-6, latest
Libgeotiff (1.1.4), latest Libtiff (3.5.7), LibJpeg 6b,
Jasper2000, Xastir NOV01, GCC3.2.
--D
Logged In: YES
user_id=448632
I can create such a display by selecting Maps->Background
Color and setting it to one of the blues, then by
deselecting Maps->Enable Area Color Fills.
You're sure you not doing that?
It could also be related to the truecolor stuff. That's
32-bit color right? I usually run 16-bit color and it works
fine.
Logged In: YES
user_id=637715
Declaring Pseudocolor instead of Autoselect or Truecolor
seems to have fixed this problem. Chances are this should
probably be in a FAQ somewhere, but it wasn't related to the
area color fills.
Glad we have that problem resolved, that was driving me
nuts. :)
Thanks.
--D
Logged In: YES
user_id=637715
Having to declare your visual is a pretty messy way to do
things, either a -visual switch or a check to see the default
visual for the display would probably be a better way to do
things.
There are some pieces of code out there where people have
implemented this... Otherwise this basically means anyone
with a good video card is hurting unless they want to break
things.
It's not a big deal to me right now since I only use Exceed for
Xastir primarily, but if I was to use CDE under Solaris, I'd be
stuck with a Pseudocolor palette, 256 colors.
I'm glad we've figured out the problem though. Because I saw
this brought up in Xastir-Dev or Xastir-User a while ago and
people blamed Exceed.. That's not the case it seems :)
In the meantime I'll leave Pseudocolor as the default visual
instead of AutoSelect, unless I feel like breaking into the
code and changing it.
Thanks for the help :)
--D
Logged In: YES
user_id=448632
We definitely need fixes in the code to handle 32-bit. I'll
keep this bug open for a while and see if we can get someone
familiar with that part of the code to look into it.
Logged In: YES
user_id=448632
Does this also happen with non ImageMagick maps? Like
Shapefiles, DOS/Win maps, geoTIFF maps, pocketAPRS maps?
Logged In: YES
user_id=637715
that's a good question.. If someone wants to direct me to
some of those types of files we can try it... I do know it
happens on Terraserver pulls, but that uses Imagemagick as
well so it's a poor example.
If you have any handy then I can throw them in, I have those
libraries installed.. can drop them to mobiledroo@1-X.net, it
doesn't have a file size limit because it's the mail server here.
Thanks.
--D
Logged In: YES
user_id=448632
Just sent one shapefile, one pocketaprs, and one WinAPRS map
your way. I picked smaller ones.
Logged In: YES
user_id=637715
Those maps work fine.. tried each one at a time to make
sure. Then when I pulled the maps and turned tigermap on,
we're back to blue again in truecolor.
Looks like an Imagemagick problem.
--D
Logged In: YES
user_id=34019
OK, it seems pretty clear where the problem comes from. I
talked to WE7U a bit on the radio last evening and I suspect
a specific area of the code (which I wrote...) I'll try and
check this out at home one of these evenings or this
weekend. I do need one more bit of info from Drew. Could
you add a comment here the output of the xdpyinfo command
when running your X server in the failing configuration.
Thanks.
Logged In: YES
user_id=637715
Tsunami# /usr/openwin/bin/xdpyinfo
name of display: Tsunami:11.0
version number: 11.0
vendor string: Hummingbird Communications Ltd.
vendor release number: 7101
maximum request size: 4194300 bytes
motion buffer size: 1
bitmap unit, bit order, padding: 8, MSBFirst, 32
image byte order: MSBFirst
number of supported pixmap formats: 4
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 12, bits_per_pixel 12, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 254
focus: PointerRoot
number of extensions: 21
BIG-REQUESTS
DOUBLE-BUFFER
Extended-Visual-Information
HCL-DOS-Access
HCLMISC
HCLxperf
LBX
MIT-SHM
Multi-Buffering
RECORD
SECURITY
SHAPE
SYNC
TOG-CUP
XC-APPGROUP
XC-MISC
XIE
XInputExtension
XTEST
XTestExtension1
XpExtension
default screen number: 0
number of screens: 2
screen #0:
dimensions: 1024x768 pixels (320x240 millimeters)
resolution: 81x81 dots per inch
depths (4): 1, 8, 12, 24
root window id: 0x2c
depth of root window: 24 planes
number of colormaps: minimum 8183, maximum 8183
default colormap: 0x20
default number of colormap cells: 256
preallocated pixels: black 0, white 16777215
options: backing-store WHEN MAPPED, save-unders YES
largest cursor: 32x32
current input event mask: 0x780000
SubstructureNotifyMask SubstructureRedirectMask
FocusChangeMask
PropertyChangeMask
number of visuals: 3
default visual id: 0x23
visual:
visual id: 0x21
class: PseudoColor
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x22
class: PseudoColor
depth: 12 planes
available colormap entries: 4096
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x23
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
screen #1:
dimensions: 13199x13199 pixels (559x559 millimeters)
resolution: 600x600 dots per inch
depths (2): 1, 24
root window id: 0x2e
depth of root window: 24 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x24
default number of colormap cells: 256
preallocated pixels: black 0, white 16777215
options: backing-store YES, save-unders YES
largest cursor: 32x32
current input event mask: 0x0
number of visuals: 1
default visual id: 0x1
visual:
visual id: 0x1
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
The Xastir project no longer uses sourceforge for issue tracking and I am closing all open issues (all of which are very old).
If this issue is still important, please open a new one on https://github.com/Xastir/Xastir.