[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Steve,

As for this,
 > In the case of GEMPAK, it will use the default visual of the
 > system, there is no way to configure it to use a different visual
 > ID.
it actually seems like it ought to be pretty easy to modify the code
to take a PseudoColor (8-bit) visual if the system has one and
otherwise to use the default.  Here is a quick C/X11 program I wrote
which does just that:

+++++++++++++++++++++++++ myxinfo.c ++++++++++++++++++++++++++++++++++++
/*    Linux: gcc -o myxinfo.`uname -s` -L/usr/X11R6/lib -lX11 myxinfo.c
 */
/*    SunOS: cc -o myxinfo.`uname -s` -lX11 myxinfo.c */
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <X11/Xlib.h>
#include <X11/Xutil.h>

main(int argc, char *argv[]) {
  void usage(void);
  Display    *dpy;
  Window      win;

  int i;
  int debug = 0;
  int scr;

  XVisualInfo viproto;          /* fill in for getting info */
  XVisualInfo *vip;                     /* retured info */
  int nvi;                              /* number of elements returned */
  int psvisual = -1;
  char *class = NULL;                   /* for printing */

  dpy = XOpenDisplay(0);
  if (!dpy)
    {
      fprintf(stdout, "Cannot open the display.\n");
      return(0);
    }
  scr = DefaultScreen(dpy);

  nvi = 0;
  viproto.screen = scr;
  vip = XGetVisualInfo (dpy, VisualScreenMask, &viproto, &nvi);
  printf (" default visual id:  0x%lx\n", 
          XVisualIDFromVisual (DefaultVisual (dpy, scr)));
  printf (" checking all %d visuals for a PseudoColor \n", nvi);
  for (i = 0; i < nvi; i++) {
    if ((vip+i)->class == PseudoColor) {
        printf ("    got PseudoColor visual for \n");
        printf ("    visual id:    0x%lx\n", (vip+i)->visualid);
        printf ("    depth:    %d plane%s\n", (vip+i)->depth, 
                (vip+i)->depth == 1 ? "" : "s");
        psvisual = i;
        break;
    }
  }
  if (psvisual == -1) {
    printf ("  ** did not find PseudoColor visual, using default \n");
    printf ("    visual id:    0x%lx\n", vip->visualid);
    printf ("    depth:    %d plane%s\n", vip->depth, 
                vip->depth == 1 ? "" : "s");
  }
  XCloseDisplay(dpy);
  return(0);

}
+++++++++++++++++++++++++ myxinfo.c ++++++++++++++++++++++++++++++++++++

Any chance this type of approach could be added to NPROGS and GEMPAK
in general?

David

Unidata Support wrote:
> David,
> 
> I don't have any experience with PC graphics cards in this manner.
> The gembud list may be a place to see if anyone else has such a
> configuration.

> I have run xnest for creating an 8 bit desktop in a 24 bit display.
> The XFree86 server at last dcheck does not allow multiple visuals,
> so even though you can have both 8 bit at 24 bit color, they both
> are true color. Note that this is a limitation of XFree86, and not
> xnest (which works fine on more advanced X servers that support
> multiple visuals).

> In the case of GEMPAK, it will use the default visual of the
> system, there is no way to configure it to use a different visual
> ID.
>
> Steve Chiswell
> 
> 
> >From: David Ovens <address@hidden>
> >Organization: UCAR/Unidata
> >Keywords: 200309191715.h8JHF9k1022085
> 
> >Steve,
> >
> >I'm now thinking about purchasing an nvidia Quadro 4 or FX card that
> >would support an 8-bit "Overlay" in 24-bit displays.  If we could have
> >the default visual as 24-bit and an optional 8-bit overlay, how could
> >I use the 8-bit one for GEMPAK?  In xanim and xv, for example, I can
> >specify any of the visuals I have present on my Sun with a
> >command-line option.  Is there a command-line option or Xresouce that
> >could do this for GEMPAK?
> >
> >By the way, I did discover that the lowest memory usage way to look at
> >the EAST-CONUS/1km/VIS imagery in NMAP/GARP is to do something like
> >"Roam" = "6 x Screen Size" and then to do a zoom.  This keeps
> >the roam area down to a limited portion of the original 5120x5120
> >image.
> >
> >David
> >
> >Unidata Support wrote:
> >> 
> >> 
> >> David,
> >> 
> >> The problem with 8 bit color under Xfree86 4.2 is that
> >> the window manager allocates most of the colors, and you
> >> are left with only 12 free color cells. There were reportedly
> >> some patches to the XFree86 to remedy that problem
> >> (I'm assuming you have the same problem under Debian as
> >> RH). Likely your old RH7.0 at home is running an older version
> >> of XFree86 (which is a good thing in this case!).
> >> 
> >> I haven't looked at the current state of XFreee86 patches since
> >> going to 24 bit under Linux. Users were doing CVS checkout of source for
> >> patches and rebuilding....hopefully its easier than that now.
> >> 
> >> Note that you can also sample the 1km gini in either
> >> space or resolution using the SECTOR program which is
> >> useful if you want 1 faster loading (less memory) image
> >> at top resolution for your area, or don't need 1km resolution for a larger 
> >> a
> > rea.
> >> 
> >> Steve Chiswell.
> >> 
> >> 
> >> 
> >> >From: David Ovens <address@hidden>
> >> >Organization: UCAR/Unidata
> >> >Keywords: 200309182106.h8IL6jk1020275
> >> 
> >> >Hello,
> >> >
> >> >I have an older version of GEMPAK on my Linux box (RedHat 7.0) at home
> >> >-- 5.6.A? 5.6.D? -- and the only way I can get it to work is to run
> >> >with PseudoColor (8-bit) not DirectColor (24-bit).  I've lived and
> >> >worked with that just fine.
> >> >
> >> >Now, I am trying to look at 10 EAST-CONUS/1km/VIS/ GINI images setting
> >> >the "Roam" to "Size of Image".  Since my giniinfo program (available
> >> >if you want it as a GEMPAK contrib program) tells me the images are
> >> >5120x5120, you can imagine that this is going to require some memory.
> >> >Close to 1 GB in 24-bit mode, but considerably less in 8-bit.
> >> >Unfortunately, at work here, I cannot seem to get any GEMPAK programs
> >> >to run under 8-bit (the opposite of home).  
> >> >
> >> >Is this due to Debian Linux at work or some change in GEMPAK?
> >> >
> >> >Any idea how I can run in 8-bit with 5.6.H or later GEMPAK on Linux?
> >> >
> >> >The types off errors I'm getting are these:
> >> >
> >> >sfmap errors:
> >> >Creating process: xw for queue 163843
> >> > [GEMPLT -46]  NCLRAL - Can not allocate read/write colors.
> >> > Parameters requested: 
> >> > AREA,GAREA,SATFIL,RADFIL,SFPARM,DATTIM,SFFILE,COLORS
> > ,
> >> > MAP,LATLON,TITLE,CLEAR,PANEL,DEVICE,PROJ,FILTER,TEXT,LUTFIL,STNPLT,CLRBAR,
> >> > IMBAR.
> >> > GEMPAK-SFMAP>e
> >> >
> >> >garp errors:
> >> >G A R P - v2.1 starting...
> >> >Warning: Cannot allocate colormap entry for "deepskyblue4"
> >> >InitGempakColorMap:  Can't allocate Graphic colors.
> >> >GarpInitialize:  GempakInit failed
> >> >Main: Initialization failed.  Exiting
> >> >
> >> >ntl errors:
> >> >Warning: Cannot allocate colormap entry for "grey75"
> >> >Resource File:  /home/disk/ldm/NAWIPS-5.6.H/resource/Ntop
> >> >graphic, satellite, radar, fax -- 33 95 20 2
> >> >         Request total # of colors = 150
> >> >X Error of failed request:  BadValue (integer parameter out of range for 
> >> >op
> > era
> >> > tion)
> >> >  Major opcode of failed request:  86 (X_AllocColorCells)
> >> >  Value in failed request:  0x0
> >> >  Serial number of failed request:  413
> >> >  Current serial number in output stream:  413
> >> >
> >> >freeColors shows 12:
> >> >                  CURRENTLY YOUR SYSTEM HAS:
> >> >          ========================================
> >> >              256 total color cells.
> >> >              12 free  color cells.
> >> >              244 shared read-only color cells.
> >> >              0 private writeable color cells.
> >> >          ========================================
> >> >
> >> >and the rest is xdpyinfo output:
> >> >name of display:    :0.0
> >> >version number:    11.0
> >> >vendor string:    The XFree86 Project, Inc
> >> >vendor release number:    40201000
> >> >XFree86 version: 4.2.1
> >> >maximum request size:  4194300 bytes
> >> >motion buffer size:  256
> >> >bitmap unit, bit order, padding:    32, LSBFirst, 32
> >> >image byte order:    LSBFirst
> >> >number of supported pixmap formats:    7
> >> >supported pixmap formats:
> >> >    depth 1, bits_per_pixel 1, scanline_pad 32
> >> >    depth 4, bits_per_pixel 8, scanline_pad 32
> >> >    depth 8, bits_per_pixel 8, scanline_pad 32
> >> >    depth 15, bits_per_pixel 16, scanline_pad 32
> >> >    depth 16, bits_per_pixel 16, scanline_pad 32
> >> >    depth 24, bits_per_pixel 32, scanline_pad 32
> >> >    depth 32, bits_per_pixel 32, scanline_pad 32
> >> >keycode range:    minimum 8, maximum 255
> >> >focus:  PointerRoot
> >> >number of extensions:    30
> >> >    BIG-REQUESTS
> >> >    DEC-XTRAP
> >> >    DOUBLE-BUFFER
> >> >    DPMS
> >> >    Extended-Visual-Information
> >> >    FontCache
> >> >    GLX
> >> >    LBX
> >> >    MIT-SCREEN-SAVER
> >> >    MIT-SHM
> >> >    MIT-SUNDRY-NONSTANDARD
> >> >    NV-CONTROL
> >> >    NV-GLX
> >> >    NVIDIA-GLX
> >> >    RECORD
> >> >    RENDER
> >> >    SECURITY
> >> >    SHAPE
> >> >    SYNC
> >> >    TOG-CUP
> >> >    XC-APPGROUP
> >> >    XC-MISC
> >> >    XFree86-Bigfont
> >> >    XFree86-DGA
> >> >    XFree86-Misc
> >> >    XFree86-VidModeExtension
> >> >    XInputExtension
> >> >    XKEYBOARD
> >> >    XTEST
> >> >    XVideo
> >> >default screen number:    0
> >> >number of screens:    1
> >> >
> >> >screen #0:
> >> >  dimensions:    1280x1024 pixels (342x271 millimeters)
> >> >  resolution:    95x96 dots per inch
> >> >  depths (7):    8, 1, 4, 15, 16, 24, 32
> >> >  root window id:    0x41
> >> >  depth of root window:    8 planes
> >> >  number of colormaps:    minimum 1, maximum 1
> >> >  default colormap:    0x20
> >> >  default number of colormap cells:    256
> >> >  preallocated pixels:    black 0, white 1
> >> >  options:    backing-store YES, save-unders YES
> >> >  largest cursor:    64x64
> >> >  current input event mask:    0x0
> >> >  number of visuals:    6
> >> >  default visual id:  0x21
> >> >  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:    GrayScale
> >> >    depth:    8 planes
> >> >    available colormap entries:    256
> >> >    red, green, blue masks:    0x0, 0x0, 0x0
> >> >    significant bits in color specification:    8 bits
> >> >  visual:
> >> >    visual id:    0x23
> >> >    class:    StaticColor
> >> >    depth:    8 planes
> >> >    available colormap entries:    256
> >> >    red, green, blue masks:    0x7, 0x38, 0xc0
> >> >    significant bits in color specification:    8 bits
> >> >  visual:
> >> >    visual id:    0x24
> >> >    class:    TrueColor
> >> >    depth:    8 planes
> >> >    available colormap entries:    8 per subfield
> >> >    red, green, blue masks:    0x7, 0x38, 0xc0
> >> >    significant bits in color specification:    8 bits
> >> >  visual:
> >> >    visual id:    0x25
> >> >    class:    DirectColor
> >> >    depth:    8 planes
> >> >    available colormap entries:    8 per subfield
> >> >    red, green, blue masks:    0x7, 0x38, 0xc0
> >> >    significant bits in color specification:    8 bits
> >> >  visual:
> >> >    visual id:    0x26
> >> >    class:    StaticGray
> >> >    depth:    8 planes
> >> >    available colormap entries:    256
> >> >    red, green, blue masks:    0x0, 0x0, 0x0
> >> >    significant bits in color specification:    8 bits
> >> >
> >> >
> >> >
> >> >Thanks,
> >> >
> >> >David
> >> >-- 
> >> >
> >> >David Ovens               e-mail: address@hidden
> >> >(206) 685-8108          plan: Real-time MM5 forecasting for Pacific 
> >> >Northwe
> > st
> >> >Research Meteorologist
> >> >Dept of Atmospheric Sciences, Box 351640
> >> >University of Washington 
> >> >Seattle, WA  98195
> >> >
> >> 
> >> ****************************************************************************
> >  <
> >> Unidata User Support                                    UCAR Unidata 
> >> Program
> >  <
> >> (303)497-8643                                                  P.O. Box 
> >> 3000
> >  <
> >> address@hidden                                   Boulder, CO 80307
> >  <
> >> ----------------------------------------------------------------------------
> >  <
> >> Unidata WWW Service              
> >> http://my.unidata.ucar.edu/content/support 
> >  <
> >> ****************************************************************************
> >  <
> >> 
> >
> >
> >-- 
> >
> >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
> >
> 
> **************************************************************************** <
> Unidata User Support                                    UCAR Unidata Program <
> (303)497-8643                                                  P.O. Box 3000 <
> address@hidden                                   Boulder, CO 80307 <
> ---------------------------------------------------------------------------- <
> Unidata WWW Service              http://my.unidata.ucar.edu/content/support  <
> **************************************************************************** <
> 


-- 

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