Re: 20030923: 20030922: 20030919: 20030918: GEMPAK and pseudo-color on Linux

> There are numerous location in the code included under
> $GEMPAK/source/driver/active/xw that call DefaultDepth, and
> apparently in NPROGS too. I would assume that the goal of having a
> resource to define a prefered depth/visual and/or your code to find
> a visual/depth/window/display would be that once these are found,
> they should be a global variables stored in the header (or could be
> externs) that would be used instead of the X server calls like
> DefaultDepth.

Steve and others,

That sounds like the logical approach.  I have been attempting to do
something like this, but have so far failed.  I am also not sure what
gets returned as the Colormap "gemmap" when I'm on a 24-bit
DirectColor or TrueColor display.  I see in "Xlib Programming Manual
Volume One" example 7-10 that I may need to "specify colormap
attribute if using nondefault visual".  I must admit that I'm in a
little over my head here, but will attempt to do what you have
suggested on the Depth issue and see if that works.

My changes to xinita.c do change to an 8-bit visual in programs such
as sfmap, gdplot2, etc. and do allow me to reset colors using the
following type of approach

  sfmap << EOF
colors = 5
DEVICE = xw
run

exit
EOF
  gpcolors << EOF
colors = 5=red
run

exit
EOF
  ## at this point on an 8-bit visual, the image is already changed,
  ## but running on a default 24-bit with an optional 8-bit visual
  ## I need to rerun to see the change
  sfmap << EOFr
colors = 5
run

EOF

This is a small improvement, because gpcolor does not even work in
standard 5.6.J on a 24-bit default visual:
 GEMPAK-GPCOLOR>r
 Parameters requested: COLORS,DEVICE.
 GEMPAK-GPCOLOR>X Error of failed request:  BadAccess (attempt to
 access private resource denied)
  Major opcode of failed request:  89 (X_StoreColors)
  Serial number of failed request:  2433
  Current serial number in output stream:  2435

However, my modified NCOLOR does not yet do anything when I click on a
color to open the pop-up color editing window.

I did one more experiment today on a PC running Linux with XFree86
4.3.0 (2 default visuals installed, an 8-bit in Ctrl-Alt-F8, and a
24-bit in Ctrl-Alt-F9) and did prove that the use of 24-bit is a waste
of memory.  Displaying 22 EAST-CONUS/1km/VIS/ GINI images (5120x5120)
from Hurricane Isabel in NMAP2 using the "Roam: Size of Image" took up
a whopping 2500MB/805M (SIZE/RES) memory in 24-bit while on the 8-bit
screen it only took 848MB/586M.

For classroom work, we may just have to tell students to use the
"Ctrl-Alt-F8" window to run GEMPAK or other large image programs.  It
would be more elegant to have a Matrox graphics card that supports
both visuals on one display and just have GEMPAK choose the 8-bit one
by default, command-line argument or X resource, but the changes to
GEMPAK may be too numerous and complicated to be worth it.

If you don't hear from me again on this issue, assume my attempts have
failed and that I using the 2-display approach.

David
--

David Ovens             e-mail: address@hidden
(206) 685-8108          plan: Real-time MM5 forecasting for Pacific Northwest
Research Meteorologist
Dept of Atmospheric Sciences, Box 351640
University of Washington 
Seattle, WA  98195