Re: [PyOpenGL-Users] A puzzle regarding running PyOpenGL interactively

[Douglas S. B. <db...@br...>]

I have confirmed that Perry's problem listed below is also a problem on my
RedHat 8.0 with an NVIDIA video binary. But I don't think that has too much to
do with the problem (except that I think it is a timing issue).

I think that this is an issue in interactive mode, but only if the system has
time to attempt a redraw before one can assign the o.redraw method. For
example, if I paste the following code all at once into the Python
interpreter, it sometimes works, sometimes doesn't:

def redraw(win = 0):
    print win

import OpenGL
from OpenGL.GL import *
from OpenGL.Tk import *
o=Opengl()
o.redraw = redraw

If I pause just a little before the last line, I get the same error.

The solution: I think that OpenGL/Tk/__init__.py should have a default redraw
method that just has a pass, like:

       def redraw(self, *dummy):
                pass


If this is added, then the error never occurs, because there is a redraw
method now. This also doesn't require a "try" to see if there is a redraw
(that could slow it down), and doesn't seem to have any adverse effects.

Hope that helps,

-Doug

Perry Greenfield <pe...@st...> said:

> We have had problems with PyOpenGL for more recent releases
> of Redhat (e.g., 6.x,7.x, 8.x) that manifest themselves in odd ways.
> This is the simplest illustration of something that works for
> some OpenGL implementations and not others.
> 
> If you start an interactive Python session and types the following
> sequence of commmands:
> 
> >>> import OpenGL
> >>> from OpenGL.GL import *
> >>> from OpenGL.Tk import *
> >>> o=Opengl()
> 
> >>> Exception in Tkinter callback
> Traceback 
> [...]
> AttributeError: 'Opengl' instance has no attribute 'redraw'
> [window turns pink]
> 
> >>> glClearColor(1,0,0,0)
> >>> glClear(GL_COLOR_BUFFER_BIT)
> 
> On some installations, this results in a Tk window appearing, and
> the last command changes the background color to red.
> On other installstions, nothing happens with the last command.
> (Nor does the window turn pink on o=Opengl()).
> The above will not work for the default installations of OpenGL
> for Redhat 8 for example (The SGI library apparently).
> 
> [A natural question is why anyone would run OpenGL in this manner.
> We use OpenGL to generate plot windows from an interactive
> command line for a scientific command-line-oriented analysis
> environment. We do not use it in the usual way of generating
> a standalone GUI application. The above test illustrates the
> installations for which the plotting windows are nonfunctional
> or not]
> 
> Does anyone understand what it is that causes PyOpenGL to stop
> working with Python's interactive mode?
> 
> When we use Mesa instead on Redhat, it works. Unfortunately some
> users have NVIDIA cards that require the NVIDIA OpenGL library
> which does not work.
> 
> We would like to understand what the fundamental problem is and 
> whether there is any solution.
> 
> Thanks, Perry Greenfield
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
> 



-- 
Douglas S. Blank,       Assistant Professor         
db...@br...,          (610)526-6501
Bryn Mawr College,  Computer Science Program
101 North Merion Ave,  Park Science Building
Bryn Mawr, PA 19010 dangermouse.brynmawr.edu