Doesn't work with Pyglet 1.2+ on Windows

[hyperknot]

On windows, if I install Pyglet either from the official google code repo or from your fork or from an installer, it terminates with the following error:

legacy / demo_simple

  File "C:\Python27\lib\site-packages\pyglet\window\win32\__init__.py", line 261
, in _create
self.context.attach(self.canvas)
  File "C:\Python27\lib\site-packages\pyglet\gl\win32.py", line 263, in attach
super(Win32ARBContext, self).attach(canvas)
  File "C:\Python27\lib\site-packages\pyglet\gl\win32.py", line 208, in attach
raise gl.ContextException('Unable to share contexts')
pyglet.gl.ContextException: Unable to share contexts

code / demo_simple

  File "C:\Python27\lib\site-packages\pyglet\window\win32\__init__.py", line 261
, in _create
self.context.attach(self.canvas)
  File "C:\Python27\lib\site-packages\pyglet\gl\win32.py", line 198, in attach
'OpenGL 3 contexts.')
pyglet.gl.ContextException: Require WGL_ARB_create_context extension to create O
penGL 3 contexts.

However, it works fine with Pyglet 1.1.4

[adamlwgriffiths]

Most... interesting...

It's trying to created a shared context?

Hmm https://code.google.com/p/pyglet/issues/detail?id=318 Are you running from an IDE? Perhaps it's inheriting the GL context of the parent process, ie, your IDE has created a GL context already.

https://code.google.com/p/pyglet/issues/detail?id=397 This one suggests that successive runs of code don't close the Pyglet GL context. Does restarting the IDE resolve the issue?

[hyperknot]

No, i'm running from command line. And it works with Pyglet 1.1.4. Videocard is a modern nvidia, so it cannot be a problem.

On 7 March 2013 09:00, Adam Griffiths notifications@github.com wrote:

Most... interesting...

It's trying to created a shared context?

Hmm https://code.google.com/p/pyglet/issues/detail?id=318 Are you running from an IDE? Perhaps it's inheriting the GL context of the parent process, ie, your IDE has created a GL context already.

https://code.google.com/p/pyglet/issues/detail?id=397 This one suggests that successive runs of code don't close the Pyglet GL context. Does restarting the IDE resolve the issue?

— Reply to this email directly or view it on GitHubhttps://github.com/adamlwgriffiths/PyGLy/issues/4#issuecomment-14549183 .

[adamlwgriffiths]

Windows, Python 2.7, 32bit?

Does this code still give you the error?

import pyglet window = pyglet.window.Window(800, 600) pyglet.app.run()

[adamlwgriffiths]

Try prepending with this. I doubt its the problem since I do that for Core profile anyway, but worth a try.

import os os.environ['PYGLET_SHADOW_WINDOW']="0"

[hyperknot]

Yes, windows, python 2.7, 32-bit.

It works (core/demo_simple), if I comment out:

major_version = 3,

        # minor_version = 2,
        # forward_compatible = True,

Also, the official pyglet examples all work.

On 7 March 2013 09:08, Adam Griffiths notifications@github.com wrote:

Windows, Python 2.7, 32bit?

Does this code still give you the error?

import pyglet window = pyglet.window.Window(800, 600) pyglet.app.run()

— Reply to this email directly or view it on GitHubhttps://github.com/adamlwgriffiths/PyGLy/issues/4#issuecomment-14549450 .

[adamlwgriffiths]

Interesting. It should be dropping back to 2.1 with that removed. But that would crash because no VAO in legacy? Weird

Try without forward compatible but cersion in. That enables legacy in core.

Either way. I'm confused! Seems its just the way on creating windows and not PyGLy itself. So that's good. Still. Want to know why it's happening.

Thanks for your persistence =)

Sent from my iPhone

On 07/03/2013, at 8:10 PM, Zsolt Ero notifications@github.com wrote:

Yes, windows, python 2.7, 32-bit.

It works (core/demo_simple), if I comment out:

major_version = 3,

minor_version = 2,

forward_compatible = True,

Also, the official pyglet examples all work.

On 7 March 2013 09:08, Adam Griffiths notifications@github.com wrote:

Windows, Python 2.7, 32bit?

Does this code still give you the error?

import pyglet window = pyglet.window.Window(800, 600) pyglet.app.run()

— Reply to this email directly or view it on GitHubhttps://github.com/adamlwgriffiths/PyGLy/issues/4#issuecomment-14549450 .

— Reply to this email directly or view it on GitHub.

[hyperknot]

And what about dropping pyglet at all? I mean just using PyOpenGL. It seems to be better supported for modern OpenGL, supports up to 4.3.

On 7 March 2013 09:16, Adam Griffiths notifications@github.com wrote:

Interesting. It should be dropping back to 2.1 with that removed. But that would crash because no VAO in legacy? Weird

Try without forward compatible but cersion in. That enables legacy in core.

Either way. I'm confused! Seems its just the way on creating windows and not PyGLy itself. So that's good. Still. Want to know why it's happening.

Thanks for your persistence =)

Sent from my iPhone

On 07/03/2013, at 8:10 PM, Zsolt Ero notifications@github.com wrote:

Yes, windows, python 2.7, 32-bit.

It works (core/demo_simple), if I comment out:

major_version = 3,

minor_version = 2,

forward_compatible = True,

Also, the official pyglet examples all work.

On 7 March 2013 09:08, Adam Griffiths notifications@github.com wrote:

Windows, Python 2.7, 32bit?

Does this code still give you the error?

import pyglet window = pyglet.window.Window(800, 600) pyglet.app.run()

— Reply to this email directly or view it on GitHub< https://github.com/adamlwgriffiths/PyGLy/issues/4#issuecomment-14549450> .

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/adamlwgriffiths/PyGLy/issues/4#issuecomment-14549747 .

[adamlwgriffiths]

PyOpenGL just provides OpenGL bindings, you still need something to provide the Windowing. Mostly, people use PyGame which is an SDL wrapper. SDL hasn't had a new release since 2009. The latest stable release doesn't support Core profile, only the development version does. And PyGame only supports the stable release. Which is just rediculous.

Pyglet is a source of a lot of headaches, but I get a decent event system out of it and cross-platform windowing.

I could move to PyGLFW (I provided a fix to enable Core profile), but it's very... C-ish. Plus it means you need to compile GLFW to get PyGLy.

Pyglet is pure python, so it's a lot easier to install.

But yeah, I've wanted to set fire to Pyglet many, many times.

[adamlwgriffiths]

It would probably be a good idea to file a bug, but also post on the Pyglet user groups. Make a basic code example that triggers it using only Pyglet.

https://code.google.com/p/pyglet/issues/list https://groups.google.com/forum/?fromgroups#!forum/pyglet-users

If you just post a bug, you won't get any help, it takes months to get responses on there. The user group usually respond within a few days.

If you make an issue / group post, put the links here so I can follow them too.

Cheers, Adam

[hyperknot]

Ah, SDL never! And what's with PyOpenGL + FreeGLUT? I've read that GLFW is the preferred library these days, but what if PyOpenGL + FreeGLUT is working well on Python?

Or, as a crazy idea: PySide? You get the full support of the Qt project + would make writing GUIs a breeze!

I'll post about my issue on the pyglet group. But it doesn't seem like a library worth investing time and energy to me! Have you ever thought about PySide (PyQt)?

On 7 March 2013 10:08, Adam Griffiths notifications@github.com wrote:

PyOpenGL just provides OpenGL bindings, you still need something to provide the Windowing. Mostly, people use PyGame which is an SDL wrapper. SDL hasn't had a new release since 2009. The latest stable release doesn't support Core profile. And PyGame only supports the stable release. Which is just rediculous.

Pyglet is a source of a lot of headaches, but I get a decent event system out of it and cross-platform windowing.

I could move to PyGLFW (I provided a fix to enable Core profile), but it's very... C-ish. Plus it means you need to compile GLFW to get PyGLy.

Pyglet is pure python, so it's a lot easier to install.

But yeah, I've wanted to set fire to Pyglet man, many times.

— Reply to this email directly or view it on GitHubhttps://github.com/adamlwgriffiths/PyGLy/issues/4#issuecomment-14551736 .

[adamlwgriffiths]

I tried the GLUT bindings that come with PyOpenGL but got nothing but errors and unsupported functions. Seems it's using older versions that dont support Core profile. Perhaps theres another method, but I've never liked GLUT nor its derivatives. Its focused more on short term demo code and tends to be buggy.

GLFW seemed fine, I almost moved to it. But I need to get an event system. It also doesn't support multiple windows. And although I doubt anyone would ever use it..... I kinda felt like I was losing functionality =P. I get hung up on trivial things sometimes, unfortunately. I could move to it if needed.

I've been tempted to use Qt / wx, but it increases the entry barrier. wxPython didn't work at all inside a virtualenv, so I didn't bother since I didn't want to contaminate my system Python.

A fork could be done without tooooo much effort. The event system would need to be replaced. I only use Pyglet for Windowing and then their event system and run loop.

The run loop is trivial to re-implement. Personally, I'd rather implement my own. I had to patch Pyglet's default one out because it's questionably implemented.

The only event I use is the window resize event. Internally I use the event system to send events between window -> viewport -> view matrix. Also transform changes so they can propagate from parent -> child, and also local transform -> world transform.

So yeah, it's not too hard.

I added Kivy support to PyGLy previously. I abstracted Pyglet and Kivy's event system and event registration so I could use it to replace the existing event code. Window creation, etc was left up to the calling code as always, no point wrapping something the user can do since they're the ones choosing the platform. But wrapping multiple libraries that are totally different isn't nice. It's doable, but you make sacrifices. I wasn't happy with the code and dropped it. I probably should've used a 3rd party event lib to avoid wrapping Kivy / Pyglet's ones, which are similar, but different in important areas.

The person I'm working with is continually telling me to drop Pyglet, because it's been such a pain. But it's the only pure Python windowing library at the moment.

I'm not personally a big fan of Qt. I developed using Qt3 and, although I've written using worse libs, I found it a thoroughly frustrating experience. Most UI libraries are, but C++ is a terrible language to implement UI's in due to the need to share code amongst totally different widgets. IMO Python would be much better due to duck-typing / dynamic nature. But good Python UI libs are rare or are bound to very specific software (PyOpenGL + PyGame tends to be the standard unfortunately).

If you want to try PySide or another library like that, I'm happy to provide help in doing so. If it proved to be trivial enough to install, I would consider merging it into mainline.

I could perhaps use a 3rd party event system (so its not mangled by trying to support kivy/pyglet/etc) and then wrap kivy / pyglet at the window level for events. That way the windowing could be provided by any lib.

[adamlwgriffiths]

New issue to explore this is here: https://github.com/adamlwgriffiths/PyGLy/issues/5