Hello,

I think those error messages are because of bugs in XQuartz.  It looks 
like they might have solved this in recent versions:

http://xquartz.macosforge.org/trac/ticket/438

I'm on an older version of XQuartz on my Mac so still get these.  But it 
doesn't seem to cause any permanent harm.  So on my machine the windows 
still will re-open ok.  (And definitely no similar issue on Linux that I 
know of.)

Wayne

On Tue, 15 Jan 2013, Jack Howarth wrote:

> On Wed, Jan 16, 2013 at 12:25:35AM +0000, Wayne Boucher wrote:
>> Hello,
>>
>> The glDirect flag has no impact on whether OpenGL is used or not.  As for
>> performance, the blurb in the GLX documentation says:
>>
>> "If direct is True, then a direct rendering context is created if the
>> implementation supports direct rendering, if the connection is to an X
>> server that is local, and if a direct rendering context is available. (An
>> implementation may return an indirect context when direct is True.) If
>> direct is False, then a rendering context that renders through the X
>> server is always created. Direct rendering provides a performance
>> advantage in some implementations."
>>
>> I would guess that a more important issue is whether the OpenGL
>> implemenation is using sensible drivers (and I don't know about Fink).
>> Others are probably better placed to comment on this in the Analysis
>> context.
>>
>> When the first window is rendered, the program prints out some OpenGL
>> messages if it is using that instead of Tk, e.g.:
>>
>> GL_VENDOR = NVIDIA Corporation
>> GL_RENDERER = NVIDIA GeForce 9400 OpenGL Engine
>> GL_VERSION = 2.1 NVIDIA-7.32.12
>>
>> To change it to use OpenGL you open the Project --> Preferences --> User
>> Options dialog, in the Main Options tab (the first tab).  It's the
>> "Graphics Handler" option about halfway down.  You need to save and
>> restart Analysis before any change takes effect.  If OpenGL is not
>> showing then the program has not been compiled with OpenGL (at least as
>> far as it thinks!).
>
> Wayne,
>    Thanks. This works with the output being...
>
> finished opening spectrum Expt_1 ghnhb_3D
> GL_VENDOR = ATI Technologies Inc.
> GL_RENDERER = ATI Radeon X1600 OpenGL Engine
> GL_VERSION = 2.1 ATI-7.4.1
>
> on my 2006 MacBook Pro. There is some noise in the output when the spectrum's
> window is closed by clicking on the red close button in the window frame though...
>
> Jan 15 19:49:06 MacBookPro.local Python[4130] <Error>: kCGErrorIllegalArgument: CGSGetWindowBounds
> Jan 15 19:49:06 MacBookPro.local Python[4130] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
> Jan 15 19:49:06 MacBookPro.local Python[4130] <Error>: kCGErrorIllegalArgument: CGSGetSurfaceBounds
> Jan 15 19:49:06 MacBookPro.local Python[4130] <Error>: kCGErrorIllegalArgument: CGSBindSurface: Invalid window 0xfb
> Jan 15 19:49:06 MacBookPro.local Python[4130] <Error>: kCGErrorIllegalArgument: CGSBindSurface: Invalid window 0xfb
> Jan 15 19:49:06 MacBookPro.local Python[4130] <Error>: kCGErrorIllegalArgument: CGSBindSurface: Invalid window 0xfb
>
> Do you get anything like that on linux?
>                 Jack
>
>
>>
>> Wayne
>>
>> On Tue, 15 Jan 2013, Jack Howarth wrote:
>>
>>> On Tue, Jan 15, 2013 at 05:49:04PM +0000, Wayne Boucher wrote:
>>>> Hello,
>>>>
>>>> I think I have found the fix and fortunately it is in the Python world so
>>>> I've added a patch to the update server.
>>>>
>>>> Wayne
>>>
>>> Wayne,
>>>   Thanks. I'll test that tonight. FYI, the MacPorts packaging of ccpnmr is
>>> based off of the previous ccpnmr fink packaging. Both build ccpnmr without
>>> using installCode.py by using the environment.txt approach. The GL support
>>> is included in the build but I am uncertain if the GL support is being
>>> defaulted on when analysis runs as -glDirect isn't passed to AnalysisGui.py.
>>> How do you tell what the gl status is in analysis when it is started without
>>> an explicit -glDirect option? Also I don't see any major differences in
>>> rendering speed for 3D spectra under tcl/tk 8.5.13 using -glDirect 1
>>> vs -glDirect 0. Is that expected?
>>>            Jack
>>> ps In both fink and MacPorts, the analysis program is started with a
>>> startup script of the form...
>>>
>>> #!/bin/sh
>>>
>>> export MallocLogFile=/dev/null
>>>
>>> if [ ${SSH_TTY} ]; then
>>>    export LIBGL_ALWAYS_INDIRECT=1
>>> fi
>>>
>>> /sw/bin/python2.7 -i -O /sw/lib/python2.7/site-packages/ccpnmr/ccpnmr2.2/python/ccpnmr/analysis/AnalysisGui.py $1 $2 $3 $4 $5
>>>
>>>
>>>
>>>> On Tue, 15 Jan 2013, Wayne Boucher wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> OK, I just built Analysis 2.2.2 with Tcl/Tk 8.6.0 and Python 2.7.3 but
>>>>> on 10.6.8 and it worked fine in OpenGL mode but crashes
>>>>> instantaneously, as for you, when just opening a pre-existing window in
>>>>> a project in Tk mode. I shall look into this (but work in OpenGL mode
>>>>> for now if that is an option in that build).
>>>>>
>>>>> Wayne
>>>>>
>>>>> On Tue, 15 Jan 2013, Jack Howarth wrote:
>>>>>
>>>>>>   The existing ccpnmr-2.2.2 package in MacPorts was broken when they
>>>>>> transitioned from tcl/tk 8.5.13 to the new tcl/tk 8.6 release. The
>>>>>> issue we are seeing, when analysis 2.2.2 is built against tcl/tk 8.6
>>>>>> and python-tk 2.7.3, is that, when the 3D spectral window display is
>>>>>> opened and rendered upon loading a ucsf file, analysis crashes with
>>>>>> the cryptic error...
>>>>>>
>>>>>>>>> Spectrum successfully opened
>>>>>> finished opening spectrum Expt_1 ghnhb_3D
>>>>>> X Error of failed request:  BadDrawable (invalid Pixmap or Window
>>>>>> parameter)
>>>>>>  Major opcode of failed request:  70 (X_PolyFillRectangle)
>>>>>>  Resource id in failed request:  0x601811
>>>>>>  Serial number of failed request:  47218
>>>>>>  Current serial number in output stream:  47221
>>>>>>
>>>>>> This issue has been filed as http://trac.macports.org/ticket/37644. Can
>>>>>> anyone test if this same issue occurs with tcl/tk 8.6 on linux?
>>>>>>        Jack
>>>>>> ps There are no obvious warnings during the compilation of analysis
>>>>>> against the newer tcl/tk. Reverting the installed tcl/tk back 8.5.13,
>>>>>> rebuilding python-tk and then analysis eliminates the crash. So far every
>>>>>> _tkinter python test I have run outside of analysis has passed for
>>>>>> tcl/tk 8.6 so it is unclear where the bug originates. These tests were
>>>>>> done on Mac OS X 10.7.5.
>>>>>>
>>>>>
>>>
>