Woops. I keep forgetting to mail the list...
For the specific import replace the PYGLET part of the header with
--------------------------------------------
if 'PYGLET' in os.environ:
from pyglet.gl import glMultMatrixf, glClearColor,
glShadeModel, glTranslated, glClear
from pyglet.gl import glColor3f, glLoadIdentity, glScalef,
glVertex3f, glNormal3f
from pyglet.gl import glBegin, glEnd, glFlush, GLfloat,
glViewport, glMatrixMode, glFrustum
from pyglet.gl import GL_TRIANGLES, GL_FLAT,
GL_COLOR_BUFFER_BIT, GL_PROJECTION, GL_MODELVIEW
def glmult(l):
return glMultMatrixf( (GLfloat * len(l))(*l) )
----------------------------------------
Regards
Crispin
On Thu, Mar 26, 2009 at 1:22 PM, Crispin Wellington
<[email protected]> wrote:
> I haven't finished reading you're whole email, but just quickly, I did
> try an explicit import...
>
> from pyglet.gl import glTranlated, GL_.... etc. etc.
>
> but it did the same locking...
>
> Crispin
>
> On Thu, Mar 26, 2009 at 1:18 PM, Bruce Smith <[email protected]> wrote:
>>
>> On Mar 25, 6:50 pm, Crispin Wellington <[email protected]>
>> wrote:
>>> ... first step would be to just get pyglet.gl OpenGL
>>> calls working on a Qt OpenGL context.
>>>
>>> What I found, at least under Mac OSX leopard, is that the calls
>>> "work", but somehow, for some reason, importing pyglet.gl freezes the
>>> QT app window. ...
>>>
>>> So now testing under OSX, the display DOES render, I get no error, and
>>> the window is locked.
>>> Testing under linux, the pyglet.gl does NOT render, but the window IS
>>> draggable. It does spit out an error on linux that it doesn't on OSX.
>>> The traceback on linux is
>>>
>>> Traceback (most recent call last):
>>> File "test.py", line 45, in paintGL
>>> glClear(GL_COLOR_BUFFER_BIT)
>>> File "/var/lib/python-support/python2.5/pyglet/gl/lib.py", line 83,
>>> in errcheck
>>> raise GLException('No GL context; create a Window first')
>>> pyglet.gl.lib.GLException: No GL context; create a Window first
>>>
>>> Anyone have any ideas how to "unlock" the window on OSX and use the
>>> pyglet.gl calls? Or how to get the GL drawing on linux?
>>
>> I get the same error (Intel Mac OS 10.5). I have a (vague) theory
>> about the cause of all the behaviors you list above: Importing
>> pyglet.gl (I speculate) doesn't only define symbols, it also does
>> something to (or using) your current GL context. (Rather than, for
>> example, requiring you to call an init function and not doing that
>> stuff until you call that function.) If so, then the behaviors you
>> describe are consistent with Linux not having any GL context current
>> when pyglet.gl is imported (which it complains about), but with Mac
>> having the *wrong* context current -- perhaps one related to being
>> able to drag the window, thus the freeze. (I.e. either Qt or the Mac
>> window manager is using OpenGL to drag the window, and has left that
>> context current when your program starts.)
>>
>> (It's certain that the context you want (the one owned by the
>> QGLWidget) can't be current yet, during that import, since it doesn't
>> even exist yet.)
>>
>> I've been involved in some Qt OpenGL programming, and seen similar
>> bugs, for example when we did anything to an OpenGL context outside of
>> paintGL (e.g. in a mouse event handler) and forgot to first call
>> makeCurrent on the QGLWidget whose context we wanted to affect. In
>> that case too, we found different bugs on Linux and Mac.
>>
>> Based on this theory, I tried fixing this in your example code by just
>> delaying the import of pyglet.gl until the desired GL context is known
>> to be current (which is first true inside initializeGL, I think), but
>> I couldn't get it to work. The problems might be trivial, related to
>> doing import * inside a function (SyntaxWarning in python 2.5) -- it
>> might be easier if you did explicit imports rather than import *.
>>
>> A better fix, if this theory is right, would be to be able to set a
>> flag which causes pyglet.gl to defer all initialization which depends
>> on having an OpenGL context current, until a specific function is
>> called (and ideally to let it be called more than once, in case of non-
>> resource-sharing contexts, but that's much more work if any global
>> variables are involved -- they'd need to become attributes of a class
>> associated with each context -- so for now we can only hope for a
>> singleton context, just one that doesn't have to exist when your
>> program starts).
>>
>> I.e. your program would look like this:
>>
>> pyglet_gl_no_implicit_init = True
>>
>> import pyglet.gl # affected by that flag
>>
>> .....
>>
>> def initializeGL(self):
>>
>> pyglet.gl.ok_now_you_can_do_that_init_stuff_that_requires_the_right_GL_context
>> ()
>> .....
>>
>> (But I couldn't easily find the right place in pyglet.gl.__init__ or
>> one of its submodules to do this.)
>>
>> (I must emphasize that this theory and proposed fix is purely
>> speculative -- the real issue could be something completely
>> different.)
>>
>> - Bruce Smith
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/pyglet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
