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

20030310: gpcolor fails in > 8-bit color in 5.6.h

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20030310: gpcolor fails in > 8-bit color in 5.6.h
  • Date: Mon, 10 Mar 2003 16:18:30 -0700
Kevin,

This appears to work under my development tree of 5.6.J which
does include some additional changes in the display drivers since 5.6.H
(due to byte flipping ...eg PCs). I will verify this on all our other
platforms as well.

Some notes on changing the color table entries:

1) the change of color won't take effect until the display is redrawn,
(unlike the indexed color map in 8bit where you change the color of the
index directly...here you are changing the index location), so
make the COLOR assigments in gpcolor before running your program (or
use the MAP=6=red in line as you mention.

2) If you freqently make the same color table changes, eg setting the
background to white, you can copy $GEMTBL/colors/coltbl.xwp to
your working directory and set the color entry in the file (the first color
is the bakground color) and coltbl.xwp will be read locally before looking in
$GEMTBL/colors.

Steve Chiswell
Unidata User Support

On Mon, 10 Mar 2003, Kevin R. Tyle wrote:

> Hi all,
>
> When I run gpcolor in 5.6.h on a screen that is set to more than 8-bit
> color, the program hangs with the following messages:
>
> $GEMEXE/gpcolor
> Creating process: gplt for queue 4450
>  COLORS    Color list                        101=WHITE
>  DEVICE    Device|name|x size;y size|color   gf
>  Parameters requested: COLORS,DEVICE.
>  GEMPAK-GPCOLOR>r
> Creating process: gf for queue 8651
>  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:  33
>   Current serial number in output stream:  33
>
> This is seen in both Solaris 8 and RH Linux 7.3.
>
> The problem also occurs when you attempt to change the color
> of a GEMPAK parameter "in-line" during execution of another
> "GP" type program; e.g. try setting MAP=4=GREEN in gpmap.
>
> Setting the display to one that is in 8-bit mode (either real
> or virtual) produces normal execution of gpcolor.
>
> Additionally, does anyone have success using GEMPAK with a
> X Virtual Frame buffer set to 8-bit color in RH 7.3?  I've tried,
> but get the dreaded Color Allocation error.  It works fine
> with a Xvfb running on Solaris 8 .. .
>
> Thanks,
>
> Kevin
> ______________________________________________________________________
> Kevin Tyle, Systems Administrator               **********************
> Dept. of Earth & Atmospheric Sciences           address@hidden
> University at Albany, ES-235                    518-442-4571 (voice)
> 1400 Washington Avenue                          518-442-5825 (fax)
> Albany, NY 12222                                **********************
> ______________________________________________________________________
>