Re: [Plplot-devel] Solaris xwin.c fix

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > Since we use mostly plplot-general and plplot-devel, it was only by accident
 > that I spotted an xwin suggestion on our forum which appears to be useful.
 > Please look at
 > http://sourceforge.net/forum/forum.php?thread_id=105137&forum_id=8607 where
 > it is stated a change to our XCreateWindow call solves all solaris problems
 > for this particular user.
 > 
 > I don't know anything about the syntax of XCreateWindow, but it appears the
 > guy used the X default depth and visual rather than the values known to
 > plplot (which I assume were either not set correctly at all and the Linux X
 > server could overcome this or had values which were legal for the Linux X
 > server but somehow illegal for the solaris X server).  I applied this change
 > (after correcting his typo where he substituted ev for dev), and it works
 > fine on my Linux box. Thus, I have gone ahead and put it in CVS as a basis
 > for further discussion.

I only just this weekend got a chance to look into this.  In the process I
reviewed all the changes to xwin.c made over the last few months.  The only
one that looks dubious is this one, so it was good that Alan prodded me to
look at it.

I found from "cvs log" the following commits having to do with visuals in
xwin.c :

----------------------------
revision 1.89
date: 2001/11/26 18:54:13;  author: airwin;  state: Exp;  lines: +9 -2
Use default depth and visual when using XCreateWindow.  This works on Linux,
and it apparently solves a problem with the solaris X server, but there may
be a better way to do this.

----------------------------
revision 1.85
date: 2001/08/31 20:27:26;  author: jcard;  state: Exp;  lines: +4 -3
remove the X error handler, needed when the xwin driver
 attempted  to store colors in a true visual colormap.

----------------------------
revision 1.69
date: 1996/10/31 05:08:04;  author: furnish;  state: Exp;  lines: +216 -51
Hack in support for using read only shared color cells when the visual
does not support read write private color cells.  Also, switch
DEVAULT_VISUAL to 0, so that we have a chance of locating a
conventional PseudoColor visual.

----------------------------
revision 1.49
date: 1994/08/25 03:58:15;  author: mjl;  state: Exp;  lines: +41 -16
Change to use default visual for now, since otherwise the current
procedure results in a BadMatch when calling XCreateWindow on some systems
(Suns).  To really get it right, XGetRGBColormaps or something similar
must be used to pair the visual with a compatible colormap.


The last one is telling.. apparently this same problem was encountered &
"fixed" by the same method 7 years ago!

The difficulty is that the new XCreateWindow completely disregards all the
work being done in GetVisual().  I can't really vouch for the code in
GetVisual() as I didn't write it (and have forgotten most of what I learned
about visuals anyway) but I assume it is there for good reason.  Further, the
visual obtained in GetVisual() is then used to set the xwd->rw_cmap, which
could be wrong if the default visual is being used.

The superior solution is as follows:
 - turn the DEFAULT_VISUAL #define at the top of xwin.c into a configuration
variable instead
 - the configure logic will set DEFAULT_VISUAL to 1 under SunOS, 0 otherwise.

For DEFAULT_VISUAL set to 1, the following lines from GetVisual() will be used:

    if ( ! visuals_matched) { 
        xwd->visual = DefaultVisual( xwd->display, xwd->screen ); 
        xwd->depth = DefaultDepth( xwd->display, xwd->screen ); 
    } 

which will plug into XCreateWindow() in the same way as the DefaultXXX calls
now.

I'll make the change.

-- 
Maurice LeBrun    mj...@ga...