Ok, I'm sorry I looked into this :-)
but I have a few workarounds, and a patch.
1) The problem only seems to occur with Exceed 6.1. The problem
does not occur with Exceed 6.0. So, one workaround is two
avoid upgrading to Exceed 6.1
http://www.hummingbird.com/exceedusers/Sep1998/0031.html
describes the following new features in 6.1
--start--
PseudoColor Emulation in Video Modes with More Than 256 Colors
PseudoColor emulation in video modes with more than 256 colors has been
improved. To obtain the best results, the following Xconfig Performance
Settings are required:
Maximum Backing Store When Mapped or Always
Default Backing Store When Mapped
Minimum Backing Store When Mapped
--end--
I suspect that this change in Exceed is what exposed the bug in vem.
2) One workaround is to change your Windows display setting to 256
colors.
3) Another workaround is to change the default colormap from TrueColor
to PseudoColor
http://www.hummingbird.com/exceedusers/Jun1997/0039.html
says:
From Xconfig select Video and change the Server Visual setting from
auto-select to Pseudocolor and your problem should dissappear.
4) The fix is to modify the vuWhite() function in
$PTOLEMY/src/octtools/vem/utility/colors.c
and use XAllocNamedColor() instead of WhitePixel()
--start--
unsigned long vuWhite(clr)
XColor *clr; /* Returned color structure */
/*
* Returns the white pixel for the display. If `clr' is
* non-zero, it will return the full color structure
* for the white pixel.
*/
{
static XColor white, exactwhite;
static int init = 0;
if (!init) {
/* Don't call WhitePixel here, instead, get the color by name.
The value for WhitePixel apparently is the value for the default
colormap. If we have a TrueColor map, then the value of
WhitePixel will be out of range if we use it with a PseudoColor
map
*/
XAllocNamedColor(xv_disp(), xv_cmap(), "white", &white, &exactwhite);
//white.pixel = WhitePixel(xv_disp(), xv_scrn());
XQueryColor(xv_disp(), xv_cmap(), &white);
}
if (clr) *clr = white;
return white.pixel;
}
--end--
The above patch solves most of the problems, though if
Default Backing Store is set to 'None', then the background of the
facets is black, and the colors are wrong.
If Default Backing Store is set to 'When mapped', then
the edges of some of the facets have black sections.
-Christopher
--------
"Hae-Sock Oh" <[EMAIL PROTECTED]> writes:
--------
I'm a user of Ptolemy..
My OS is Windows NT4.0 with service pack4.
and I install Ptolemy to Sun Ultra1..
I use Ptolemy with Exceed6.1 for NT....but..
there's problem with pigi..
Error message is as follows....
BadValue (integer parameter out of range for operation)
Request X_QueryColors(minor code 0)
--------
I've seen this message as well under NT4.0sp3 with Exceed6.1
However, I was using the Cygwin port, so I thought that the problem
was with the port, not the window system.
Since you are seeing the same problem when running pigi under Solaris,
then that indicates that the problem is with vem itself, and not
the Cygwin port.
I don't think I had this problem with Exceed6.0, and I poked around on
the Hummingbird website and did not find any mention of this problem.
One workaround is to set your display for 256 colors.
I'll see if I can reproduce this problem using the Solaris pigi
The error appears twice. The first error is coming from vem:
#10 0x417701 in vemXError (theDisp=0xa034ba0, theError=0x274f358)
at ../../../../src/octtools/vem/main/errors.c:132
#11 0x670b2d04 in _size_of_stack_reserve__ ()
#12 0x670b1719 in _size_of_stack_reserve__ ()
#13 0x670a3dc6 in _size_of_stack_reserve__ ()
#14 0x4340e1 in vuWhite (clr=0x274f48c)
at ../../../../src/octtools/vem/utility/color.c:57
#15 0x417296 in vemInitCursors ()
at ../../../../src/octtools/vem/main/cursors.c:119
#16 0x4173c5 in vemCursor (curName=0)
at ../../../../src/octtools/vem/main/cursors.c:168
#17 0x412e29 in main (argc=1, argv=0xa031918)
at ../../../../src/octtools/vem/main/vem.c:463
The offending line is in vuWhite():
XQueryColor(xv_disp(), xv_cmap(), &white);
The XQueryColor man page says:
BadValue Some numeric value falls outside the range of
values accepted by the request. Unless a specific
range is specified for an argument, the full range
defined by the argument's type is accepted. Any
argument defined as a set of alternatives can gen-
erate this error.
I poked around with the debugger, and I can see that there is a
strange value at one point, but it looks like that value is
being returned by the window system.
-Christopher
---------------------------------------------------------------------------
-
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
--------
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
